From emcmurry@computer.org Tue Jul 2 19:59:28 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 5988A21F8D0D for ; Tue, 2 Jul 2013 19:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tayQMiNWoKyd for ; Tue, 2 Jul 2013 19:59:23 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id A6E9021F8CDD for ; Tue, 2 Jul 2013 19:59:23 -0700 (PDT) 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 1UuDHu-0003bt-HD for dime@ietf.org; Wed, 03 Jul 2013 02:59:22 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 470D975A395 for ; Tue, 2 Jul 2013 21:59:20 -0500 (CDT) 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: U2FsdGVkX1+pyLneTnrqVso+Os8nHsTMSlUgaTQZwtg= 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 nolSwAA1Lvhg for ; Tue, 2 Jul 2013 21:59:20 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 20E7E75A38C for ; Tue, 2 Jul 2013 21:59:20 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Tue, 2 Jul 2013 21:59:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01C9FDE4-3C4B-4B27-8FD9-260ECBA846C0@computer.org> References: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl 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, 03 Jul 2013 02:59:28 -0000 any other thoughts on this? Right now, this, and the discussion that Ben started on non-supporting = elements are the only open discussions on this draft. I expect more = when folks dig into it some more. I can do another spin of this before = Berlin and I'm interested in hearing thoughts on the discussion points = raised on the list or any others people have upon review. Thanks! Eric On Jun 26, 2013, at 22:45 , Ben Campbell wrote: >=20 > On Jun 26, 2013, at 5:24 PM, Eric McMurry = wrote: >=20 >> There are use cases for Diameter overload control where it would be = useful for a server to be able to throttle traffic from a specific = source. When the source is adjacent to the server, this can be = accomplished easily enough by the server just sending the overload = control information directly to the source in question. >>=20 >> However, when there are intermediaries between the server and the = source (client), the current proposed mechanism in = draft-roach-dime-overload-ctrl does not have a way to do this. Adding a = scope for origin-host would solve this issue. The way this would work = would be for the server to construct the overload control information = and attach the origin-host scope to it that matches the specific source = of overload it wants to target. The information would be ignored by any = other recipients as they would not have an origin-host that matches that = scope when sending messages. >=20 > This could also be used by an agent to throttle traffic from a = specific client, since it could match the actual origin-host value in a = request to the origin-host scope value. >=20 >>=20 >> I think this could be an optional scope as it wouldn't be needed for = all applications that may use Diameter overload control. >>=20 >=20 > I agree it should be optional for agents. I'm on the fence for = clients, but optional is probably okay there. If people specify = application specific behavior for certain applications, they could = always mandate it there. >=20 >> Thoughts? >>=20 >>=20 >>=20 >> Thanks! >>=20 >> Eric >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From md3135@att.com Sat Jul 6 07:23:28 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 E33D521F9BC1 for ; Sat, 6 Jul 2013 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[AWL=1.964, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ll+ThTqod22 for ; Sat, 6 Jul 2013 07:23:23 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3579021F9BCF for ; Sat, 6 Jul 2013 07:23:22 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a5828d15.2aab0405f940.1657500.00-550.4597535.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 06 Jul 2013 14:23:22 +0000 (UTC) X-MXL-Hash: 51d8285a7620c6a7-dbccd94d66e67b2d2a05b27e09230f0c77966d0b Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 65828d15.0.1657497.00-283.4597525.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 06 Jul 2013 14:23:21 +0000 (UTC) X-MXL-Hash: 51d8285927fe5fb2-13b42ecb5edc04a9612dafc13eec897b49a87bba Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r66ENI3J018132; Sat, 6 Jul 2013 10:23:18 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r66EN6vg018090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jul 2013 10:23:14 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 6 Jul 2013 14:22:57 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Sat, 6 Jul 2013 10:23:07 -0400 From: "DOLLY, MARTIN C" To: Eric McMurry , "dime@ietf.org" Thread-Topic: [Dime] origin-host scope for draft-roach-dime-overload-ctrl Thread-Index: AQHOd5lh4q3bYgjNJ0WQ/L97oRfajJlW58+w Date: Sat, 6 Jul 2013 14:23:07 +0000 Message-ID: References: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org> <01C9FDE4-3C4B-4B27-8FD9-260ECBA846C0@computer.org> In-Reply-To: <01C9FDE4-3C4B-4B27-8FD9-260ECBA846C0@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.95.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=z1WcK6hGbuEA:10 a=2RwS7dAUbLMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=oZSuqN6UwD4A:10 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8] X-AnalysisOut: [ a=8qSefF8wAAAA:8 a=i5qX4_8FtSEs1xx3OzYA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=0MAqpqVwYqEA:10 a=mHZC5r8sFEQA:10 a] X-AnalysisOut: [=5iQTKWOe0x2LPeFg:21 a=ZI_lVp2AA3eF1kMb:21] Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl 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: Sat, 06 Jul 2013 14:23:29 -0000 Eric Ben, I am assuming that understands their deployment needs.=20 Ex:=20 1. for deployments where a carrier does HSS pooling, the Agent needs to sup= port Diameter OL, and deployment on an Agent must be first of the network e= lements. 2. for mid-to large PCC deployments, the Agent needs to support Diameter OL= , and deployment on an Agent must be first of the network elements. So, I do not see the value the origin-host scope, yet... I do not see a need to support requirement/capabilities for " non-supportin= g elements", this will be addressed by deployments. Regards, Martin=20 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: Tuesday, July 02, 2013 10:59 PM To: dime@ietf.org Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl any other thoughts on this? Right now, this, and the discussion that Ben started on non-supporting elem= ents are the only open discussions on this draft. I expect more when folks= dig into it some more. I can do another spin of this before Berlin and I'= m interested in hearing thoughts on the discussion points raised on the lis= t or any others people have upon review. Thanks! Eric On Jun 26, 2013, at 22:45 , Ben Campbell wrote: >=20 > On Jun 26, 2013, at 5:24 PM, Eric McMurry wrote: >=20 >> There are use cases for Diameter overload control where it would be usef= ul for a server to be able to throttle traffic from a specific source. Whe= n the source is adjacent to the server, this can be accomplished easily eno= ugh by the server just sending the overload control information directly to= the source in question. >>=20 >> However, when there are intermediaries between the server and the source= (client), the current proposed mechanism in draft-roach-dime-overload-ctrl= does not have a way to do this. Adding a scope for origin-host would solv= e this issue. The way this would work would be for the server to construct= the overload control information and attach the origin-host scope to it th= at matches the specific source of overload it wants to target. The informa= tion would be ignored by any other recipients as they would not have an ori= gin-host that matches that scope when sending messages. >=20 > This could also be used by an agent to throttle traffic from a specific c= lient, since it could match the actual origin-host value in a request to th= e origin-host scope value. >=20 >>=20 >> I think this could be an optional scope as it wouldn't be needed for all= applications that may use Diameter overload control. >>=20 >=20 > I agree it should be optional for agents. I'm on the fence for clients, b= ut optional is probably okay there. If people specify application specific = behavior for certain applications, they could always mandate it there. >=20 >> Thoughts? >>=20 >>=20 >>=20 >> Thanks! >>=20 >> Eric >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 Sat Jul 6 14:20:17 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 3BD2921F9C4C for ; Sat, 6 Jul 2013 14:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9L9ZBFYDnfi for ; Sat, 6 Jul 2013 14:20:16 -0700 (PDT) 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 5CB2021F9B38 for ; Sat, 6 Jul 2013 14:20:16 -0700 (PDT) Received: from [10.0.1.12] (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 r66LK9e9086175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 16:20:10 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Sat, 6 Jul 2013 16:20:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <44BE4F23-8008-4565-AABF-B513CFCC3066@nostrum.com> References: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org> <01C9FDE4-3C4B-4B27-8FD9-260ECBA846C0@computer.org> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl 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: Sat, 06 Jul 2013 21:20:17 -0000 Hi Martin, The origin-host scope is mostly orthogonal to the non-supporting agent = issue. The use case for origin-host is when you have a single client = that starts sending too much traffic, and you want to reduce messages = from just that client. The actual throttling could occur in the client, = or in an intervening agent. Thanks! Ben. On Jul 6, 2013, at 9:23 AM, "DOLLY, MARTIN C" wrote: > Eric > Ben, >=20 > I am assuming that understands their deployment needs.=20 >=20 > Ex:=20 > 1. for deployments where a carrier does HSS pooling, the Agent needs = to support Diameter OL, and deployment on an Agent must be first of the = network elements. > 2. for mid-to large PCC deployments, the Agent needs to support = Diameter OL, and deployment on an Agent must be first of the network = elements. >=20 > So, I do not see the value the origin-host scope, yet... >=20 > I do not see a need to support requirement/capabilities for " = non-supporting elements", this will be addressed by deployments. >=20 > Regards, >=20 > Martin=20 >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Eric McMurry > Sent: Tuesday, July 02, 2013 10:59 PM > To: dime@ietf.org > Subject: Re: [Dime] origin-host scope for = draft-roach-dime-overload-ctrl >=20 > any other thoughts on this? >=20 > Right now, this, and the discussion that Ben started on non-supporting = elements are the only open discussions on this draft. I expect more = when folks dig into it some more. I can do another spin of this before = Berlin and I'm interested in hearing thoughts on the discussion points = raised on the list or any others people have upon review. >=20 > Thanks! >=20 > Eric >=20 >=20 > On Jun 26, 2013, at 22:45 , Ben Campbell wrote: >=20 >>=20 >> On Jun 26, 2013, at 5:24 PM, Eric McMurry = wrote: >>=20 >>> There are use cases for Diameter overload control where it would be = useful for a server to be able to throttle traffic from a specific = source. When the source is adjacent to the server, this can be = accomplished easily enough by the server just sending the overload = control information directly to the source in question. >>>=20 >>> However, when there are intermediaries between the server and the = source (client), the current proposed mechanism in = draft-roach-dime-overload-ctrl does not have a way to do this. Adding a = scope for origin-host would solve this issue. The way this would work = would be for the server to construct the overload control information = and attach the origin-host scope to it that matches the specific source = of overload it wants to target. The information would be ignored by any = other recipients as they would not have an origin-host that matches that = scope when sending messages. >>=20 >> This could also be used by an agent to throttle traffic from a = specific client, since it could match the actual origin-host value in a = request to the origin-host scope value. >>=20 >>>=20 >>> I think this could be an optional scope as it wouldn't be needed for = all applications that may use Diameter overload control. >>>=20 >>=20 >> I agree it should be optional for agents. I'm on the fence for = clients, but optional is probably okay there. If people specify = application specific behavior for certain applications, they could = always mandate it there. >>=20 >>> Thoughts? >>>=20 >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Eric >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From md3135@att.com Sat Jul 6 17:03:03 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 1D2A821F9D29 for ; Sat, 6 Jul 2013 17:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.915 X-Spam-Level: X-Spam-Status: No, score=-4.915 tagged_above=-999 required=5 tests=[AWL=1.684, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxs9CAmJXjec for ; Sat, 6 Jul 2013 17:02:57 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB521F9A61 for ; Sat, 6 Jul 2013 17:02:56 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 130b8d15.2aab06863940.1530200.00-574.4238437.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 07 Jul 2013 00:02:57 +0000 (UTC) X-MXL-Hash: 51d8b0310f20db35-71ea718f41abf4ea37eda6a7c44047d600f6de19 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id d20b8d15.0.1530163.00-499.4238324.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 07 Jul 2013 00:02:56 +0000 (UTC) X-MXL-Hash: 51d8b0307843491c-c34aa0e3a41bce8b093d9c026118246fc1d528a0 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6702q75014806; Sat, 6 Jul 2013 20:02:53 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6702dIR014690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jul 2013 20:02:47 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 7 Jul 2013 00:02:28 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Sat, 6 Jul 2013 20:02:39 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell Thread-Topic: [Dime] origin-host scope for draft-roach-dime-overload-ctrl Thread-Index: AQHOd5lh4q3bYgjNJ0WQ/L97oRfajJlW58+wgAGJO4D//+nh4A== Date: Sun, 7 Jul 2013 00:02:38 +0000 Message-ID: References: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org> <01C9FDE4-3C4B-4B27-8FD9-260ECBA846C0@computer.org> <44BE4F23-8008-4565-AABF-B513CFCC3066@nostrum.com> In-Reply-To: <44BE4F23-8008-4565-AABF-B513CFCC3066@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.95.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=H+ZsNZki c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=sOvRozpSBkkA:10 a=2RwS7dAUbLMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=oZSuqN6UwD4A:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=8qSefF8wAAAA:8 a=t4ypx_fLxkjT4x5da7gA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=0MAqpqVwYqEA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a] X-AnalysisOut: [=mHZC5r8sFEQA:10 a=CNDo0U2BnUIdoxMX:21 a=zSLZ4N-o5I69p3LC:] X-AnalysisOut: [21] Cc: "dime@ietf.org" Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 00:03:03 -0000 Ben, Thanks, that was not clear to me, but it is now. I will look to see if it is this clear in the draft and if the reasons for = the other scopes are simply explained. Regards, Martin -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Saturday, July 06, 2013 5:20 PM To: DOLLY, MARTIN C Cc: Eric McMurry; dime@ietf.org Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl Hi Martin, The origin-host scope is mostly orthogonal to the non-supporting agent issu= e. The use case for origin-host is when you have a single client that start= s sending too much traffic, and you want to reduce messages from just that = client. The actual throttling could occur in the client, or in an interveni= ng agent. Thanks! Ben. On Jul 6, 2013, at 9:23 AM, "DOLLY, MARTIN C" wrote: > Eric > Ben, >=20 > I am assuming that understands their deployment needs.=20 >=20 > Ex:=20 > 1. for deployments where a carrier does HSS pooling, the Agent needs to s= upport Diameter OL, and deployment on an Agent must be first of the network= elements. > 2. for mid-to large PCC deployments, the Agent needs to support Diameter = OL, and deployment on an Agent must be first of the network elements. >=20 > So, I do not see the value the origin-host scope, yet... >=20 > I do not see a need to support requirement/capabilities for " non-support= ing elements", this will be addressed by deployments. >=20 > Regards, >=20 > Martin=20 >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of E= ric McMurry > Sent: Tuesday, July 02, 2013 10:59 PM > To: dime@ietf.org > Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl >=20 > any other thoughts on this? >=20 > Right now, this, and the discussion that Ben started on non-supporting el= ements are the only open discussions on this draft. I expect more when fol= ks dig into it some more. I can do another spin of this before Berlin and = I'm interested in hearing thoughts on the discussion points raised on the l= ist or any others people have upon review. >=20 > Thanks! >=20 > Eric >=20 >=20 > On Jun 26, 2013, at 22:45 , Ben Campbell wrote: >=20 >>=20 >> On Jun 26, 2013, at 5:24 PM, Eric McMurry wrote: >>=20 >>> There are use cases for Diameter overload control where it would be use= ful for a server to be able to throttle traffic from a specific source. Wh= en the source is adjacent to the server, this can be accomplished easily en= ough by the server just sending the overload control information directly t= o the source in question. >>>=20 >>> However, when there are intermediaries between the server and the sourc= e (client), the current proposed mechanism in draft-roach-dime-overload-ctr= l does not have a way to do this. Adding a scope for origin-host would sol= ve this issue. The way this would work would be for the server to construc= t the overload control information and attach the origin-host scope to it t= hat matches the specific source of overload it wants to target. The inform= ation would be ignored by any other recipients as they would not have an or= igin-host that matches that scope when sending messages. >>=20 >> This could also be used by an agent to throttle traffic from a specific = client, since it could match the actual origin-host value in a request to t= he origin-host scope value. >>=20 >>>=20 >>> I think this could be an optional scope as it wouldn't be needed for al= l applications that may use Diameter overload control. >>>=20 >>=20 >> I agree it should be optional for agents. I'm on the fence for clients, = but optional is probably okay there. If people specify application specific= behavior for certain applications, they could always mandate it there. >>=20 >>> Thoughts? >>>=20 >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Eric >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nh.jones01@gmail.com Mon Jul 8 21:28:00 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 1D35221F9BAD for ; Mon, 8 Jul 2013 21:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D95kQRHjblLM for ; Mon, 8 Jul 2013 21:27:59 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E47F711E811B for ; Mon, 8 Jul 2013 21:27:57 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so5002976pbb.20 for ; Mon, 08 Jul 2013 21:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:x-priority:x-mailer :mime-version:content-transfer-encoding:content-type; bh=TFgFNS+sLBVLdrjyCbqYMsx2QK66EzKjZwxaaRw8jOA=; b=ZU1Or//IODkkICFbaC6rGhjLpcpGECb0WDtJ0XsvZjHKhc+N91WLvTaCV6W1E+HBdo AdPqnHKOeijmXjm6tEracSK3ceK5tugKRQ0Ks3EdUUTItzvsQ+l7ucBei0AwQgj6j/Cf bvLr3Z/R4wT4R3a45pZPwZe/MuW++QqhzelcXEcQfA1Gnw4S7FG+KXHLY8R2EzInsL8+ 6sb7c0SAnEXgi8yB+NqzcsMMbbOb4zdjc6cVkq4a3svkxB7Jub1SqIiF6cLbdxSte7vS VKIgfNIzRxYJnmMKPuTwWVfT4e2WBt9GZD18la6oLJ3PDE2dK/zbBsOIYUDvEd+VXUB6 7PDQ== X-Received: by 10.66.144.170 with SMTP id sn10mr26312996pab.42.1373344077493; Mon, 08 Jul 2013 21:27:57 -0700 (PDT) Received: from www.queryhome.com (ec2-54-245-79-134.us-west-2.compute.amazonaws.com. [54.245.79.134]) by mx.google.com with ESMTPSA id wr9sm25814934pbc.7.2013.07.08.21.27.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Jul 2013 21:27:56 -0700 (PDT) Date: Tue, 9 Jul 2013 04:27:55 +0000 To: dime@ietf.org From: Norah Jones Message-ID: X-Priority: 3 X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Subject: [Dime] The Role of DIAMETER in IMS? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Norah Jones List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 04:28:00 -0000 Hi, Probably I know the part of the answer, still want to understand and debate the full role on Diameter Protocol in IMS. Diameter is used in all interfaces where AAA service is required in LTE may be more then 50+ interfaces are there where diameter is required. Now the question is - can we say similar thing about the IMS too or still Radius rules in IMS. Thanks, Norah Jones From hannes.tschofenig@gmx.net Tue Jul 9 00:54:44 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 E127D21F9F8A for ; Tue, 9 Jul 2013 00:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6+JRmxZ7qUd for ; Tue, 9 Jul 2013 00:54:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id CEC3521F9F4C for ; Tue, 9 Jul 2013 00:54:36 -0700 (PDT) Received: from [172.16.254.103] ([80.92.116.131]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQ2Wx-1UrFxB3iMd-005Imt; Tue, 09 Jul 2013 09:54:35 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig X-Priority: 3 In-Reply-To: Date: Tue, 9 Jul 2013 10:54:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1C777DBC-A058-423A-9541-46A1AD4ECFC4@gmx.net> References: To: Norah Jones X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:rSRw2di/3+fjnja3xY8yosgQkgqNu4WZAsCtd+7RjCUSK5kwFri leuXWPzGw8LucKOTuN9XhDt20Gqf1VsRsfGPT3VzLTxmLT6NVMobQTfyg0FI50Mj7au+urr IDtjvHnL9pmN7g/FhA/B4C2Pcd0bxlwt7rhKLYnY++eHblO8gEk6guWKF2zimweTWvqUJsX RGa3aYf4nw5SWsiAcm9bw== Cc: dime@ietf.org Subject: Re: [Dime] The Role of DIAMETER in IMS? 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, 09 Jul 2013 07:54:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 IMS also uses Diameter (not RADIUS). =20 In mobile networks Diameter is used all over the place.=20 Ciao Hannes On Jul 9, 2013, at 7:27 AM, Norah Jones wrote: > Hi,=20 >=20 > Probably I know the part of the answer, still want to understand and = debate the full role on Diameter Protocol in IMS. Diameter is used in = all interfaces where AAA service is required in LTE may be more then 50+ = interfaces are there where diameter is required. Now the question is - = can we say similar thing about the IMS too or still Radius rules in IMS. >=20 >=20 > Thanks, > Norah Jones >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR28G4AAoJEGhJURNOOiAtklkH/0qGmmVYurQxT4ibfMT5vFvh XB6eWrYj/kclkd/fcRaX6mxA0zJ8L3VPTKl+HSqzosRvYy8C92GnIj6xe6gGvowo XaRwkb0xo20mHETBPSDFkw9pPgA+RUYGLpdJO+rcMQHfsmHX0Vz2niDIXYIjjG/X k5OaHzc9NIe2xdKJv1OsSOV9ZhPlFMcaxbC3q+pcw34D5hOwQ4ha6edBFd8gWznL Fttq0i9z05NfDmG/lAqajMNprBGaWl1k1chfCEh9rA52zo290oGIlpIDTzUxj9QI YcGvLy2DNuf5YEzRqtMe7WoCujYheBKmxPjTx58tGmc3Y/Vb0jMz2P+GZAc/A4s=3D =3DoHOB -----END PGP SIGNATURE----- From jouni.nospam@gmail.com Tue Jul 9 01:32:28 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 02FB721F9F0A for ; Tue, 9 Jul 2013 01:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZKmKjf77f5d for ; Tue, 9 Jul 2013 01:32:27 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD1E21F9EF8 for ; Tue, 9 Jul 2013 01:32:27 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf17so2206296bkc.7 for ; Tue, 09 Jul 2013 01:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=jE28paOJcwSjIU7OvQrjjh3V+3XgmgcPvhxqw9yjwPY=; b=oSlxMF8cTAu+5N5l4ekN+e+E1N9QOhs1ag14SZrzJUeQ8ndVoNwAiOWk3L2YAVa1Yq JIIdMmhbwvpbhNwq3+TfKcC3BSiwz4iLrzKJQRITEVaZ2iiYGVmTHJvmKgR5W+ZneycV +Q1w568BPe379SXHEI/6tvOYmru8644taoFAjkQZ8WwhylqzBltfndUfNr0LAlpNkK/r ptUpphkBAiHQW/kV9aMfXGQ1p0/TwlT1iu4kv3czwjDlBYbflUuk8Gp1XjBaJCW4VSF1 lpGHUIstI5Xqy50TbYedPxSqOjKP51PkScW6gb14qgMco1oggo2eniOa2r9vlYdZIrP9 7mIA== X-Received: by 10.205.44.198 with SMTP id uh6mr4049653bkb.46.1373358745060; Tue, 09 Jul 2013 01:32:25 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id m6sm5269443bki.7.2013.07.09.01.32.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 01:32:24 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Jouni Korhonen X-Priority: 3 In-Reply-To: Date: Tue, 9 Jul 2013 11:32:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Norah Jones X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] The Role of DIAMETER in IMS? 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, 09 Jul 2013 08:32:28 -0000 Actually, IMS was the first thing in 3GPP to pick up Diameter in Rel-5. = I-WLAN followed in Rel-6 and then in Rel-8 rest of the places where = things like SS7 was used earlier. You can still find RADIUS in 3GPP specs (as of Rel-12) in (S)Gi = interface between the GGSN/PGW and the external network AAA server (like = corporate RADIUS server). - Jouni On Jul 9, 2013, at 7:27 AM, Norah Jones wrote: > Hi,=20 >=20 > Probably I know the part of the answer, still want to understand and = debate the full role on Diameter Protocol in IMS. Diameter is used in = all interfaces where AAA service is required in LTE may be more then 50+ = interfaces are there where diameter is required. Now the question is - = can we say similar thing about the IMS too or still Radius rules in IMS. >=20 >=20 > Thanks, > Norah Jones >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nh.jones01@gmail.com Thu Jul 11 03:15: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 881FA21F9FE2 for ; Thu, 11 Jul 2013 03:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33nW0vDoJYEe for ; Thu, 11 Jul 2013 03:15:11 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89821F9F76 for ; Thu, 11 Jul 2013 03:15:09 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so7741808pbc.24 for ; Thu, 11 Jul 2013 03:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:x-priority:x-mailer :mime-version:content-transfer-encoding:content-type; bh=KtT7bJtL1ia7XnEIgCDJqJH0OFXhPuIoZSOHl8aUCLU=; b=JsjMovn6FJrwgK3QxUopwNqIHC9QKIfP5Epe28x+EJEcjl6jYWvniLgTDXTH0Kgthc fj2BxIgQKdGKdeq/PznUEwVRpd1iiu8QxnBjwrqsrdTaai4nL4YIcuVwnoghxJVI8p4/ OpPRo1WFU2JI0RMDzuonev2aVCl9dSJLWsaev6Cyw+uGLJsVJRm1GhJXUvRyB9LaooOF eG+S1vLkP8TYQYHLeDE80t1xZg2yHZDTtydZEwd/I7+Ve4OMnvIwz3oxOw9ZTyKy+C4y owZ/xYFeKL5dvlxzZ1719jdK20S/auW+nw4mJoJMehGtPzRh1D8AVg5sQMWAQ0+ZHoOJ q62A== X-Received: by 10.68.166.5 with SMTP id zc5mr36123809pbb.16.1373537708961; Thu, 11 Jul 2013 03:15:08 -0700 (PDT) Received: from queryhome.com (ec2-54-245-79-134.us-west-2.compute.amazonaws.com. [54.245.79.134]) by mx.google.com with ESMTPSA id fr1sm38932889pbb.26.2013.07.11.03.15.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Jul 2013 03:15:08 -0700 (PDT) Date: Thu, 11 Jul 2013 10:15:07 +0000 To: dime@ietf.org From: Norah Jones Message-ID: X-Priority: 3 X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Subject: [Dime] Difference between Relay, Proxy and Redirect Agent of Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Norah Jones List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:15:11 -0000 Hi, Thanks, Norah Jones From isj-dime@i1.dk Thu Jul 11 03:37: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 50CBE21F9D6B for ; Thu, 11 Jul 2013 03:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kASJsVIbOvCW for ; Thu, 11 Jul 2013 03:37:36 -0700 (PDT) Received: from i1.dk (isjsys5-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:20d:93ff:fe73:ac12]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9D21F9CAC for ; Thu, 11 Jul 2013 03:37:35 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 60CF75C008D for ; Thu, 11 Jul 2013 12:37:32 +0200 (CEST) Received: from isjsys.int.i1.dk (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTP for ; Thu, 11 Jul 2013 12:37:32 +0200 (CEST) Received: from isjsys.int.i1.dk (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id 3441526E28 for ; Thu, 11 Jul 2013 12:37:32 +0200 (CEST) From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= To: dime@ietf.org Date: Thu, 11 Jul 2013 12:37:32 +0200 Message-ID: <2642269.Pf9Wej75Zg@isjsys.int.i1.dk> User-Agent: KMail/4.10.3 (Linux/3.7.10-1.16-desktop; KDE/4.10.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Dime] Difference between Relay, Proxy and Redirect Agent of Diameter 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, 11 Jul 2013 10:37:36 -0000 On Thursday 11 July 2013 10:15:07 Norah Jones wrote: > Hi, > > Thanks, > Norah Jones This is explained in RFC3588 section 2.8 From qh.resu01@gmail.com Fri Jul 12 05:13:16 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 2B3E021E804E for ; Fri, 12 Jul 2013 05:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61D-0R-X2n1H for ; Fri, 12 Jul 2013 05:13:15 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C187221E804D for ; Fri, 12 Jul 2013 05:13:15 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so8937397pbc.31 for ; Fri, 12 Jul 2013 05:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:x-priority:x-mailer :mime-version:content-transfer-encoding:content-type; bh=Kd0B8o0/lJ88wikf/XvDDaQcH6pufuOWdVnais0PMlk=; b=eDokiKzsKe0EzK6BIv9QmIZlAyzF8cdtuW1WmBWTsUQK+AA4rOLkc3/3lXjur4lKRw JJJNA0fkasQRucMXNa9Oazt5xsjbadQldi4waN7Y3iJanStxM6J19sHSwcVPb/cbIa9V kaz496iHUzlvq2z+gAd+9Tzm5gnXFmy/HRFEPYLkGa4FzkD54yVdENMWhUmtJ4sP89Q0 CRD63aVadpnoV2mSLl4ZXHyNdT5jGtWMGFwZnDNREAGwj1SySLdR7VAVCqEIT0QPn2A9 cMrF0rZGaPYQuXuev67pFcMuPYbVwhZ1z7ck2nqK+kKGtwo/M70RRMPwQZArsaNqsDVD xqRQ== X-Received: by 10.68.217.170 with SMTP id oz10mr41784096pbc.152.1373631195528; Fri, 12 Jul 2013 05:13:15 -0700 (PDT) Received: from queryhome.com (ec2-54-245-79-134.us-west-2.compute.amazonaws.com. [54.245.79.134]) by mx.google.com with ESMTPSA id ep4sm17552657pbd.35.2013.07.12.05.13.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jul 2013 05:13:14 -0700 (PDT) Date: Fri, 12 Jul 2013 12:13:12 +0000 To: dime@ietf.org From: Kevin Peterson Message-ID: X-Priority: 3 X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Subject: [Dime] which 3GPP spec has message level details about Sp interface between PCRF and HSS/SPR ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Kevin Peterson List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:13:16 -0000 Hi, I have a requirement where I want to fetch User Subscriber Full details at PCRF. Can anyone please tell me about exact 3GPP specification number ? Thanks, Kevin Peterson From alanmcn@openet.com Fri Jul 12 05:51:49 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 81CEF11E8128 for ; Fri, 12 Jul 2013 05:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKc7IabGtL9Y for ; Fri, 12 Jul 2013 05:51:45 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7E95821F9AAE for ; Fri, 12 Jul 2013 05:51:34 -0700 (PDT) Received: from [85.158.137.19:47919] by server-6.bemta-3.messagelabs.com id D3/FB-00484-ACBFFD15; Fri, 12 Jul 2013 12:51:22 +0000 X-Env-Sender: alanmcn@openet.com X-Msg-Ref: server-16.tower-39.messagelabs.com!1373633481!12932812!1 X-Originating-IP: [212.187.194.139] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26031 invoked from network); 12 Jul 2013 12:51:21 -0000 Received: from unknown.level3.net (HELO dubhbca02.openet-dublin) (212.187.194.139) by server-16.tower-39.messagelabs.com with RC4-SHA encrypted SMTP; 12 Jul 2013 12:51:21 -0000 Received: from DUBEXCH01.openet-dublin ([10.0.3.84]) by dubhbca02.openet-dublin ([10.0.3.81]) with mapi; Fri, 12 Jul 2013 13:51:21 +0100 From: Alan McNamee To: Kevin Peterson , "dime@ietf.org" Date: Fri, 12 Jul 2013 13:51:20 +0100 Thread-Topic: [Dime] which 3GPP spec has message level details about Sp interface between PCRF and HSS/SPR ? Thread-Index: Ac5++TLXbjUH1vH5R/+T7jJYb95bAgABPvCA Message-ID: <53CF299802A281409CB89D5E3DDC4AF70A8EDDAD12@DUBEXCH01.openet-dublin> References: In-Reply-To: Accept-Language: en-US, en-IE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-IE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Jul 2013 11:41:32 -0700 Subject: Re: [Dime] which 3GPP spec has message level details about Sp interface between PCRF and HSS/SPR ? 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, 12 Jul 2013 12:51:49 -0000 Hi Kevin, You should start with 3GPP TS 23.203 http://www.3gpp.org/ftp/Specs/html-info/23203.htm Have a look at section 5.2.3 If you are looking for a standardised interface I would consider Ud over Sp= . Regards, Alan. -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Kev= in Peterson Sent: 12 July 2013 13:13 To: dime@ietf.org Subject: [Dime] which 3GPP spec has message level details about Sp interfac= e between PCRF and HSS/SPR ? Hi, I have a requirement where I want to fetch User Subscriber Full details at = PCRF. Can anyone please tell me about exact 3GPP specification number ? Thanks, Kevin Peterson _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you are not the intended recipient, please note that any review, dissemi= nation, disclosure, alteration, printing, circulation, retention or transmi= ssion of this e-mail and/or any file or attachment transmitted with it, is = prohibited and may be unlawful. If you have received this e-mail or any fil= e or attachment transmitted with it in error please notify postmaster@opene= t.com. Although Openet has taken reasonable precautions to ensure no viruse= s are present in this email, we cannot accept responsibility for any loss o= r damage arising from the use of this email or attachments. From jouni.nospam@gmail.com Fri Jul 12 13:37: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 6140C21F9A70 for ; Fri, 12 Jul 2013 13:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoHdP2NWYS07 for ; Fri, 12 Jul 2013 13:37:36 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4C21F9D7C for ; Fri, 12 Jul 2013 13:37:30 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so3928325bkc.18 for ; Fri, 12 Jul 2013 13:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4m2w4Ysx4apMYGwyO7p17R3zbyGCwsoILQuA5WqOzXQ=; b=GzTgME4PzMAQgI5xyMGlDJFWaFDMG55XtjIkuLWI8ze9twWc/Uq0ZIb1AxcOE5Tbta bGdndzNN53Vna5eERaj8MEl9+Lrf+sG2GdY2uG6u31HewSzEIz/9wLlKeANSXnmxpBYC 97N1DccBB5928wTvYCijUh2+w0bk7pArG61Gi3yJM8if6YiT0MYg9FxPMFK2DnOwS1ig rokMYJyoajz3TIj0NslIH3gdmCNAFnQpFG/7r2mjfCQrcTsWzputfTwhjZr26yYXhBTO WNblQ2GIb3/Pwyfykpe++5VOYXdPTgRQTjMVBCmr+FyExE+dQ5R2dtC/Yp1Lv8G7O3+S QKKQ== X-Received: by 10.204.235.69 with SMTP id kf5mr6719884bkb.86.1373661449286; Fri, 12 Jul 2013 13:37:29 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:d092:efaf:3186:bc93? ([2001:1bc8:101:f101:d092:efaf:3186:bc93]) by mx.google.com with ESMTPSA id ok9sm9552782bkb.8.2013.07.12.13.37.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 13:37:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <6C04FADA-FC2F-4B60-9F0C-1CB04AD356AC@gmail.com> Date: Fri, 12 Jul 2013 23:37:26 +0300 Content-Transfer-Encoding: 7bit Message-Id: <92DF24A1-E884-46F4-8696-2605D667D17B@gmail.com> References: <9A4AC6D9-BDB5-414E-8DF1-7BC42594250A@gmail.com> <6C04FADA-FC2F-4B60-9F0C-1CB04AD356AC@gmail.com> To: "DiME@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] Call for agenda items for IETF#87 Berlin meeting 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, 12 Jul 2013 20:37:36 -0000 Just a reminder.. - Jouni & Lionel On Jun 18, 2013, at 10:43 AM, Jouni Korhonen wrote: > > Just a reminder. > > - Jouni & Lionel > > > On May 26, 2013, at 6:35 PM, Jouni wrote: > >> Folks, >> >> We have requested for two hour meeting slot. If you feel like >> presenting your work (be that in the current charter or not), >> send a request to the co-chairs. Obviously, chartered items >> will be prioritized over other topics. >> >> - Jouni & Lionel >> > From md3135@att.com Sun Jul 14 05:45:01 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 E0FBC11E8122 for ; Sun, 14 Jul 2013 05:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPgs2wBGU8vI for ; Sun, 14 Jul 2013 05:44:54 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 26AF421E8084 for ; Sun, 14 Jul 2013 05:44:53 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f3d92e15.0.4071373.00-167.11297052.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 14 Jul 2013 12:44:53 +0000 (UTC) X-MXL-Hash: 51e29d45701d590a-3e7a481ac62609d92f17c2187f8e962edd201543 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECil2Z019725; Sun, 14 Jul 2013 08:44:47 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECiT6t019669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 08:44:30 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 12:44:19 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 08:44:19 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "Ben Campbell (ben@nostrum.com)" Thread-Topic: Diameter Overload - Session Scope Thread-Index: Ac6Aj9rLa5EEUclpSMaejYEFoX1djA== Date: Sun, 14 Jul 2013 12:44:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.64] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F399MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=rqdnNplCdiQA:10 a=fiMHTXGnKj4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=dEQgIAiiB] X-AnalysisOut: [YcA:10 a=s9sG__00E8JED3c9yhUA:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=XDCXALu6ItwA:10 a=Hz7IrDYlS0cA:10 a=zdDZyafRcq] X-AnalysisOut: [4A:10 a=oFD6SnPaIm8A:10 a=TqVCwbfnxC0A:10 a=K_hhvzb-_irYyP] X-AnalysisOut: [e_hZsA:9 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=DV2FbbhnbVG] X-AnalysisOut: [zR82D:21] Subject: [Dime] Diameter Overload - Session Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:45:01 -0000 --_000_E42CCDDA6722744CB241677169E836560220F399MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, How useful is the Session Scope? Particularly, when Session-Group Scope is = used? Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560220F399MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ben,
 
How useful is the Session Scope? Particularly, when Session-Group Scop= e is used?
 
Thanks,
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560220F399MISOUT7MSGUSR9I_-- From md3135@att.com Sun Jul 14 05:47:19 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 3109221E804D for ; Sun, 14 Jul 2013 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE-M2R+h5oZa for ; Sun, 14 Jul 2013 05:47:12 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3794811E8122 for ; Sun, 14 Jul 2013 05:47:12 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fcd92e15.0.4071717.00-235.11297931.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 14 Jul 2013 12:47:12 +0000 (UTC) X-MXL-Hash: 51e29dd07b4b5fa2-7dba92ea1194faf84a14fbd33826aaa583e6166c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6EClBxN020325; Sun, 14 Jul 2013 08:47:11 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECl4ns020289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 08:47:04 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 12:46:50 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 08:46:50 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "Ben Campbell (ben@nostrum.com)" Thread-Topic: Diameter Overload - Destination-Realm Scope Thread-Index: Ac6AkDUy1MsciilEQoeja9lcJjMG7Q== Date: Sun, 14 Jul 2013 12:46:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.64] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F3C6MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=rqdnNplCdiQA:10 a=Jkg0KUANjK0A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=qgGGS4-UN] X-AnalysisOut: [gEA:10 a=d4u-BWRSE8-slXs7FFAA:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=Hz7IrDYlS0cA:10 a=ZcZVNQiV3IoA:10 a=h-eNZHL1TX] X-AnalysisOut: [UA:10 a=2OLFgjBqEmoPY5gwYboA:9 a=_W_S_7VecoQA:10 a=frz4AuC] X-AnalysisOut: [g-hUA:10 a=DV2FbbhnbVGzR82D:21] Subject: [Dime] Diameter Overload - Destination-Realm Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:47:19 -0000 --_000_E42CCDDA6722744CB241677169E836560220F3C6MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, Does Destination-Realm Scope have to be mandatory? We do not see a use for = it in our network deployment. Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560220F3C6MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ben,
 
Does Destination-Realm Scope have to be mandatory? We do not see a use= for it in our network deployment.
 
Thanks,
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560220F3C6MISOUT7MSGUSR9I_-- From md3135@att.com Sun Jul 14 05:49:40 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 093BA21E8083 for ; Sun, 14 Jul 2013 05:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.692 X-Spam-Level: X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv95O9l1+fj8 for ; Sun, 14 Jul 2013 05:49:33 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 09EE321E804D for ; Sun, 14 Jul 2013 05:49:32 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c5e92e15.0.4072012.00-401.11298704.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 14 Jul 2013 12:49:33 +0000 (UTC) X-MXL-Hash: 51e29e5d350acdd9-271ded10e9ab7b97c43bedf64d21a8c3e58a2640 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECnW1J020975; Sun, 14 Jul 2013 08:49:32 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECnQhw020958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 08:49:26 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 12:49:14 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 08:49:14 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "Ben Campbell (ben@nostrum.com)" Thread-Topic: Diameter Overload - Host vs Connection Scope Thread-Index: Ac6AkIpXn6/NaEbsTKuQr/w6v1YU4A== Date: Sun, 14 Jul 2013 12:49:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.64] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F3F0MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=rqdnNplCdiQA:10 a=7GNH53gVMDsA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=PnqcRIp7R] X-AnalysisOut: [bMA:10 a=cHmtl2r6P91rM3ynYygA:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=XDCXALu6ItwA:10 a=Hz7IrDYlS0cA:10 a=ZvWRrp5AHB] X-AnalysisOut: [8A:10 a=mjbBvtPvzxMA:10 a=TqVCwbfnxC0A:10 a=09qXEHJokTVyAT] X-AnalysisOut: [RejkoA:9 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=DV2FbbhnbVG] X-AnalysisOut: [zR82D:21] Subject: [Dime] Diameter Overload - Host vs Connection Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:49:40 -0000 --_000_E42CCDDA6722744CB241677169E836560220F3F0MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, Is there a need for both Connection and Host Scopes? If so why? Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560220F3F0MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ben,
 
Is there a need for both Connection and Host Scopes? If so why?
 
Thanks,
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560220F3F0MISOUT7MSGUSR9I_-- From md3135@att.com Sun Jul 14 05:52: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 06AC521E8088 for ; Sun, 14 Jul 2013 05:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZwxEJMMy7L5 for ; Sun, 14 Jul 2013 05:52:43 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 00EC121E804D for ; Sun, 14 Jul 2013 05:52:42 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 81f92e15.0.5823941.00-419.16148573.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 14 Jul 2013 12:52:42 +0000 (UTC) X-MXL-Hash: 51e29f1a48834ced-c6dffb93ae3db7143957a55a09205fef0998578a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECqeX5021736; Sun, 14 Jul 2013 08:52:40 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECqZjN021713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 08:52:35 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 12:52:23 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 08:52:23 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "Ben Campbell (ben@nostrum.com)" Thread-Topic: Diameter Overload - Default "Implicit" Scope Thread-Index: Ac6AkPt9WmLHlk2/TcKLA1L3YPNX5A== Date: Sun, 14 Jul 2013 12:52:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.64] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F434MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=rqdnNplCdiQA:10 a=7KzWuZyCOOEA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=zi06l9EGx] X-AnalysisOut: [j4A:10 a=NXRhLSOlxEuu2DfU8cAA:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=Hz7IrDYlS0cA:10 a=wupJu2tXM3MA:10 a=utYNj7Uk4n] X-AnalysisOut: [MA:10 a=t1on7oZFiB2LzMj1rBAA:9 a=_W_S_7VecoQA:10 a=frz4AuC] X-AnalysisOut: [g-hUA:10 a=qoiiXX2bgiSvz-BD:21] Subject: [Dime] Diameter Overload - Default "Implicit" Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:52:50 -0000 --_000_E42CCDDA6722744CB241677169E836560220F434MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, Is it possible to define a base default "implicit" Scope, where the Applica= tion-ID and the Connection Scopes are mandatory? We see these two being the minimum to be supported independent of the deplo= yment scenario. Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560220F434MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ben,
 
Is it possible to define a base default “implicit” Scope, = where the Application-ID and the Connection Scopes are mandatory?
 
We see these two being the minimum to be supported independent of the = deployment scenario.
 
Thanks,
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560220F434MISOUT7MSGUSR9I_-- From md3135@att.com Sun Jul 14 05:54:48 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 F10F121F9CA9 for ; Sun, 14 Jul 2013 05:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF-if5Xj04QP for ; Sun, 14 Jul 2013 05:54:41 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B7A5C21E804D for ; Sun, 14 Jul 2013 05:54:40 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 09f92e15.0.5824180.00-158.16149178.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 14 Jul 2013 12:54:40 +0000 (UTC) X-MXL-Hash: 51e29f9030afc3c5-11d5b9d99ff1512b777f1b6b5802b900e077233a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECseks022230; Sun, 14 Jul 2013 08:54:40 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ECsZTU022207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 08:54:35 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 12:54:26 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 08:54:26 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "Ben Campbell (ben@nostrum.com)" Thread-Topic: Diameter Overload - Destination-Host Scope Thread-Index: Ac6AkURKbXr/GOtnS5u6yA7l1YIszw== Date: Sun, 14 Jul 2013 12:54:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.64] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F461MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=rqdnNplCdiQA:10 a=XroGHeK_IpcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=nSH788WcN] X-AnalysisOut: [MkA:10 a=Dq5td-q-O2zJZG3yAa0A:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=XDCXALu6ItwA:10 a=Hz7IrDYlS0cA:10 a=VS12w-7jav] X-AnalysisOut: [UA:10 a=lnJK-oBF8koA:10 a=TqVCwbfnxC0A:10 a=GDUoes2NRN-B2q] X-AnalysisOut: [U_0TkA:9 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=DV2FbbhnbVG] X-AnalysisOut: [zR82D:21] Subject: [Dime] Diameter Overload - Destination-Host Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:54:48 -0000 --_000_E42CCDDA6722744CB241677169E836560220F461MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, Can you describe scenarios where Destination-Host Scope would be used? Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560220F461MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ben,
 
Can you describe scenarios where Destination-Host Scope would be used?=
 
Thanks,
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560220F461MISOUT7MSGUSR9I_-- From md3135@att.com Sun Jul 14 06:00:25 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 0DB2821E8085 for ; Sun, 14 Jul 2013 06:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrwJ80R+5Mt2 for ; Sun, 14 Jul 2013 06:00:18 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7821E805E for ; Sun, 14 Jul 2013 06:00:17 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0e0a2e15.0.5824978.00-442.16151260.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 14 Jul 2013 13:00:17 +0000 (UTC) X-MXL-Hash: 51e2a0e15e7d44ff-1200e0695d61822b42443e3dbf24cad34d2ceb1f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ED0G17024344; Sun, 14 Jul 2013 09:00:16 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ED095v024309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 09:00:09 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 12:59:49 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 08:59:49 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "Ben Campbell (ben@nostrum.com)" Thread-Topic: Diameter Overload - Conveying Load/Overload information in Connection messages Thread-Index: Ac6AkgVgi5P6vguIRwio7WsoQcozRQ== Date: Sun, 14 Jul 2013 12:59:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.64] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F497MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=rqdnNplCdiQA:10 a=hDHdStAC_0AA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=XL7tib14X] X-AnalysisOut: [FsA:10 a=W4MOX40T3CTei_eEoTMA:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=Hz7IrDYlS0cA:10 a=lVLCcZkrDk8A:10 a=LbsxgmRrM4] X-AnalysisOut: [YA:10 a=jPiBs4cdt69ZAzAv128A:9 a=_W_S_7VecoQA:10 a=frz4AuC] X-AnalysisOut: [g-hUA:10 a=Z_4kn7L7lr81pzqO:21] Subject: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 13:00:25 -0000 --_000_E42CCDDA6722744CB241677169E836560220F497MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, Everyone agrees that load/overload information needs to be conveyed in Appl= ication level messages. Under what circumstances is there a benefit conveying the load/overload in= formation in diameter Connection level messages (e.g., DRA, DRW)? Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560220F497MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ben,
 
Everyone agrees that load/overload information needs to be conveyed in= Application level messages.
 
Under what circumstances  is there a benefit conveying the load/o= verload information in diameter Connection level messages (e.g., DRA, DRW)?=
 
Thanks,
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560220F497MISOUT7MSGUSR9I_-- From emcmurry@computer.org Sun Jul 14 07:41:14 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 040E421F93F3 for ; Sun, 14 Jul 2013 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52mm84sK7Xa9 for ; Sun, 14 Jul 2013 07:41:09 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0429E11E8124 for ; Sun, 14 Jul 2013 07:41:01 -0700 (PDT) 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 1UyNTx-000BiU-HH; Sun, 14 Jul 2013 14:41:01 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 352F1A107D0; Sun, 14 Jul 2013 09:41:00 -0500 (CDT) 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: U2FsdGVkX19AqaKpnydl4LgUm0jpjVoxvvipkoTdm0g= 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 AXrVCHlpr1j2; Sun, 14 Jul 2013 09:41:00 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id E5428A107B9; Sun, 14 Jul 2013 09:40:59 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_10E0A617-D1EE-4502-8CF6-95700697C9F7" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Sun, 14 Jul 2013 09:40:58 -0500 Message-Id: References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 14:41:14 -0000 --Apple-Mail=_10E0A617-D1EE-4502-8CF6-95700697C9F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, The main use of DWR/DWA for this would be quiescent connections. Take a = case where an overload condition has caused a server to request a = complete traffic backoff. Once that happens, until the timer on that = overload control information pops, the clients won't send any traffic = for scope encompassed by that backoff request. If that server recovers = before that backoff period, the client will still not send it any = traffic. Using a DWR though, the server can send new control = information at any time, so that it could indicate to the client when it = has recovered, so that traffic can begin flowing. The real use of this = is to ensure that links don't stay quiescent any longer than necessary. = The general difference though between using the watchdog messages vs. = other applications is that they can be sent in an ad hoc fashion without = side effects. Thanks, Eric On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: > Ben, > =20 > Everyone agrees that load/overload information needs to be conveyed in = Application level messages. > =20 > Under what circumstances is there a benefit conveying the = load/overload information in diameter Connection level messages (e.g., = DRA, DRW)? > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_10E0A617-D1EE-4502-8CF6-95700697C9F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

The main use of DWR/DWA for this would be = quiescent connections.  Take a case where an overload condition has = caused a server to request a complete traffic backoff.  Once that = happens, until the timer on that overload control information pops, the = clients won't send any traffic for scope encompassed by that backoff = request.  If that server recovers before that backoff period, the = client will still not send it any traffic.  Using a DWR though, the = server can send new control information at any time, so that it could = indicate to the client when it has recovered, so that traffic can begin = flowing.  The real use of this is to ensure that links don't stay = quiescent any longer than necessary.  The general difference though = between using the watchdog messages vs. other applications is that they = can be sent in an ad hoc fashion without side = effects.

Thanks,

Eric


On Jul 14, 2013, at 7:59 , "DOLLY, = MARTIN C" <md3135@att.com> = wrote:

+1-609-903-3360<= /div>
 
 
 
____= ___________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime

= --Apple-Mail=_10E0A617-D1EE-4502-8CF6-95700697C9F7-- From emcmurry@computer.org Sun Jul 14 07:41:14 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 58DB521F93F3 for ; Sun, 14 Jul 2013 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCNfjOA-zc4X for ; Sun, 14 Jul 2013 07:41:09 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0D521F85E6 for ; Sun, 14 Jul 2013 07:41:09 -0700 (PDT) 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 1UyNU4-000Lts-3U; Sun, 14 Jul 2013 14:41:08 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id CAEA0A1081C; Sun, 14 Jul 2013 09:41:07 -0500 (CDT) 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: U2FsdGVkX18qYTdCgRwDL6ouPqLGoLviMFqKaycNexU= 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 riZJ2RCf7DTy; Sun, 14 Jul 2013 09:41:07 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id BF6CBA10807; Sun, 14 Jul 2013 09:41:07 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E1C265FC-62FE-4CF0-B28B-3DAFD6D1915B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Sun, 14 Jul 2013 09:41:07 -0500 Message-Id: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 14:41:14 -0000 --Apple-Mail=_E1C265FC-62FE-4CF0-B28B-3DAFD6D1915B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Martin, Technically that should be possible. I have some concern about mixing = implicit and explicit scopes though. That could be confusing. I would = think it won't be that hard to put those two scopes into control = information they apply to.=20 Perhaps others have thoughts on mixing implicit and explicit scopes? Thanks! Eric On Jul 14, 2013, at 7:52 , "DOLLY, MARTIN C" wrote: > Ben, > =20 > Is it possible to define a base default =93implicit=94 Scope, where = the Application-ID and the Connection Scopes are mandatory? > =20 > We see these two being the minimum to be supported independent of the = deployment scenario. > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_E1C265FC-62FE-4CF0-B28B-3DAFD6D1915B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Martin,

Technically that should be possible.  I = have some concern about mixing implicit and explicit scopes though. =  That could be confusing.  I would think it won't be that hard = to put those two scopes into control information they apply = to. 

Perhaps others have thoughts on = mixing implicit and explicit = scopes?

Thanks!

Eric





On Jul 14, 2013, at 7:52 , "DOLLY, MARTIN C" <md3135@att.com> wrote:

+1-609-903-3360<= /div>
 
 
 
____= ___________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime

= --Apple-Mail=_E1C265FC-62FE-4CF0-B28B-3DAFD6D1915B-- From emcmurry@computer.org Sun Jul 14 07:41: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 A7EEC21F941D for ; Sun, 14 Jul 2013 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuDHUeJ7IA4X for ; Sun, 14 Jul 2013 07:41:14 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7962F21F8456 for ; Sun, 14 Jul 2013 07:41:09 -0700 (PDT) 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 1UyNU1-000Ls2-FL; Sun, 14 Jul 2013 14:41:05 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 5AA14A107EE; Sun, 14 Jul 2013 09:41:04 -0500 (CDT) 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: U2FsdGVkX1+nxZ6i/4Tu+DefPbGJI+Yv7WuJuZOsW8M= 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 eq9TMa7jHbrt; Sun, 14 Jul 2013 09:41:04 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 47DDDA107DC; Sun, 14 Jul 2013 09:41:04 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_29E0B766-4C9A-4EF1-A7C4-ECDC68AAB876" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Sun, 14 Jul 2013 09:41:04 -0500 Message-Id: References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Destination-Host Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 14:41:18 -0000 --Apple-Mail=_29E0B766-4C9A-4EF1-A7C4-ECDC68AAB876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, I think this could be one of the most used scopes. Any time you want to = throttle traffic towards a single server, or a cluster masquerading as a = single server, this would be the go to scope. For example, consider an MME (mobility management) sending traffic to a = cluster of HSSs (subscriber DBs) where the topology of the HSS cluster = is not hidden. Let's also assume that the HSSs in the cluster are = responsible for different subscribers, and so may go into overload = independently. If one of these HSSs goes into overload, it could then = use the destination-host scope towards the MME to request that MME to = reduce traffic that it sends to just that HSS. Traffic towards other = HSSs would not be affected. Does that make sense? Thanks, Eric On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" wrote: > Ben, > =20 > Can you describe scenarios where Destination-Host Scope would be used? > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_29E0B766-4C9A-4EF1-A7C4-ECDC68AAB876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

I think this could be one of the most used = scopes.  Any time you want to throttle traffic towards a single = server, or a cluster masquerading as a single server, this would be the = go to scope.

For example, consider an MME =  (mobility management) sending traffic to a cluster of HSSs = (subscriber DBs) where the topology of the HSS cluster is not hidden. =  Let's also assume that the HSSs in the cluster are responsible for = different subscribers, and so may go into overload independently. =  If one of these HSSs goes into overload, it could then use the = destination-host scope towards the MME to request that MME to reduce = traffic that it sends to just that HSS.  Traffic towards other HSSs = would not be affected.

Does that make = sense?

Thanks,

Eric


On Jul 14, 2013, at 7:54 , "DOLLY, = MARTIN C" <md3135@att.com> = wrote:

Ben,
 
Can you = describe scenarios where Destination-Host Scope would be = used?
 
Thanks,
 
Martin= Dolly
Lead Member Technical Staff
Core & = Government/Regulatory Standards
AT&T Labs
md3135@att.com
+1-609-903-3360<= /div>
 
 
 
____= ___________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime

= --Apple-Mail=_29E0B766-4C9A-4EF1-A7C4-ECDC68AAB876-- From md3135@att.com Sun Jul 14 07:53:03 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 A434121F9C5D for ; Sun, 14 Jul 2013 07:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVWuROXkhHsG for ; Sun, 14 Jul 2013 07:52:57 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6D86121F9C89 for ; Sun, 14 Jul 2013 07:52:57 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 94bb2e15.2aaad200f940.4091981.00-514.11351883.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 14 Jul 2013 14:52:57 +0000 (UTC) X-MXL-Hash: 51e2bb49262c3ada-67ce4962a181940fad42c4842868ad1e2cd19bf2 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 64bb2e15.0.4091975.00-482.11351868.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 14 Jul 2013 14:52:56 +0000 (UTC) X-MXL-Hash: 51e2bb482f6a21ba-5d6ddb40f4aed78c196eaddb555dfa2986e5c5b4 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6EEqrXq030342; Sun, 14 Jul 2013 10:52:54 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6EEqgsi030278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 10:52:42 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 14 Jul 2013 14:52:36 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 10:52:36 -0400 From: "DOLLY, MARTIN C" To: Eric McMurry Thread-Topic: [Dime] Diameter Overload - Destination-Host Scope Thread-Index: Ac6AkURKbXr/GOtnS5u6yA7l1YIszwAMG18AAAgY8LA= Date: Sun, 14 Jul 2013 14:52:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.84.199] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560220F646MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=I2NEsM9p4cUA:10 a=h_8xxfSCxxkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=QZ08sFCZT] X-AnalysisOut: [NQA:10 a=8qSefF8wAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 ] X-AnalysisOut: [a=d_2ws3Jk8SsKWIHfPLkA:9 a=CjuIK1q_8ugA:10 a=qM39cor4HRgA:] X-AnalysisOut: [10 a=mHZC5r8sFEQA:10 a=lZB815dzVvQA:10 a=0MAqpqVwYqEA:10 a] X-AnalysisOut: [=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=JpOfS67bH5c_QAeL:21] Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Destination-Host Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 14:53:03 -0000 --_000_E42CCDDA6722744CB241677169E836560220F646MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, Does this assume that the server needs to have knowledge of the topology to= which it is deployed in order to determine which Scope to send? Thanks, Martin From: Eric McMurry [mailto:emcmurry@computer.org] Sent: Sunday, July 14, 2013 10:41 AM To: DOLLY, MARTIN C Cc: dime@ietf.org; Ben Campbell (ben@nostrum.com) Subject: Re: [Dime] Diameter Overload - Destination-Host Scope Hi Martin, I think this could be one of the most used scopes. Any time you want to th= rottle traffic towards a single server, or a cluster masquerading as a sing= le server, this would be the go to scope. For example, consider an MME (mobility management) sending traffic to a cl= uster of HSSs (subscriber DBs) where the topology of the HSS cluster is not= hidden. Let's also assume that the HSSs in the cluster are responsible fo= r different subscribers, and so may go into overload independently. If one= of these HSSs goes into overload, it could then use the destination-host s= cope towards the MME to request that MME to reduce traffic that it sends to= just that HSS. Traffic towards other HSSs would not be affected. Does that make sense? Thanks, Eric On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" > wrote: Ben, Can you describe scenarios where Destination-Host Scope would be used? Thanks, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E42CCDDA6722744CB241677169E836560220F646MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 <= /p>

Does this assume that the= server needs to have knowledge of the topology to which it is deployed in = order to determine which Scope to send?

 <= /p>

Thanks,=

 <= /p>

Martin<= /p>

 <= /p>

From: Eric McM= urry [mailto:emcmurry@computer.org]
Sent: Sunday, July 14, 2013 10:41 AM
To: DOLLY, MARTIN C
Cc: dime@ietf.org; Ben Campbell (ben@nostrum.com)
Subject: Re: [Dime] Diameter Overload - Destination-Host Scope<= /o:p>

 

Hi Martin,

 

I think this could be one of the most used scopes. &= nbsp;Any time you want to throttle traffic towards a single server, or a cl= uster masquerading as a single server, this would be the go to scope.<= /o:p>

 

For example, consider an MME  (mobility managem= ent) sending traffic to a cluster of HSSs (subscriber DBs) where the topolo= gy of the HSS cluster is not hidden.  Let's also assume that the HSSs = in the cluster are responsible for different subscribers, and so may go into overload independently.  If one of th= ese HSSs goes into overload, it could then use the destination-host scope t= owards the MME to request that MME to reduce traffic that it sends to just = that HSS.  Traffic towards other HSSs would not be affected.

 

Does that make sense?

 

Thanks,

 

Eric

 

 

On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C&quo= t; <md3135@att.com> wrote:=



Ben,

 

Can you describe scenarios where Destin= ation-Host Scope would be used?

 

Thanks,

 

Martin Dolly
Lead Member Technical Staff

Core & Government/Regulatory Standa= rds
AT&T Labs
md3135@att.com<= /a>

+1-609-903-3360

 

 

 

___________________________________________= ____
DiME mailing list
DiME@ietf.org
https://www.ietf.org= /mailman/listinfo/dime

 

--_000_E42CCDDA6722744CB241677169E836560220F646MISOUT7MSGUSR9I_-- From emcmurry@computer.org Sun Jul 14 08:19:43 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 DD4ED21E805E for ; Sun, 14 Jul 2013 08:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A6o53dpLoD4 for ; Sun, 14 Jul 2013 08:19:34 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id A01E321E808D for ; Sun, 14 Jul 2013 08:19:32 -0700 (PDT) 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 1UyO5D-000C2t-OC; Sun, 14 Jul 2013 15:19:32 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 7D234A1203D; Sun, 14 Jul 2013 10:19:30 -0500 (CDT) 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: U2FsdGVkX19oXeCOGWB9CHdY/XLn/AyUQWuu0iQJOts= 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 mTfiAUJUQTO1; Sun, 14 Jul 2013 10:19:30 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 48CBBA12029; Sun, 14 Jul 2013 10:19:30 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E474E40-4146-44CD-9CC3-2A0BD6A46695" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Sun, 14 Jul 2013 10:19:29 -0500 Message-Id: References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Destination-Host Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 15:19:45 -0000 --Apple-Mail=_2E474E40-4146-44CD-9CC3-2A0BD6A46695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, I think servers will likely be provisioned with knowledge of what scopes = they can be authoritative for, and they need access to information for = those scopes. It comes down to whoever sends control information for a = scope needs to know enough to report for that scope. So for this example, the HSSs would need to know that they are = authoritative for their hostname and that it is not being shared with = other servers. They shouldn't need to know anything else about the = topology to use the destination-host scope. Thanks, Eric On Jul 14, 2013, at 9:52 , "DOLLY, MARTIN C" wrote: > Eric, > =20 > Does this assume that the server needs to have knowledge of the = topology to which it is deployed in order to determine which Scope to = send? > =20 > Thanks, > =20 > Martin > =20 > From: Eric McMurry [mailto:emcmurry@computer.org]=20 > Sent: Sunday, July 14, 2013 10:41 AM > To: DOLLY, MARTIN C > Cc: dime@ietf.org; Ben Campbell (ben@nostrum.com) > Subject: Re: [Dime] Diameter Overload - Destination-Host Scope > =20 > Hi Martin, > =20 > I think this could be one of the most used scopes. Any time you want = to throttle traffic towards a single server, or a cluster masquerading = as a single server, this would be the go to scope. > =20 > For example, consider an MME (mobility management) sending traffic to = a cluster of HSSs (subscriber DBs) where the topology of the HSS cluster = is not hidden. Let's also assume that the HSSs in the cluster are = responsible for different subscribers, and so may go into overload = independently. If one of these HSSs goes into overload, it could then = use the destination-host scope towards the MME to request that MME to = reduce traffic that it sends to just that HSS. Traffic towards other = HSSs would not be affected. > =20 > Does that make sense? > =20 > Thanks, > =20 > Eric > =20 > =20 > On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" wrote: >=20 >=20 > Ben, > =20 > Can you describe scenarios where Destination-Host Scope would be used? > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_2E474E40-4146-44CD-9CC3-2A0BD6A46695 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

I think servers will likely be provisioned = with knowledge of what scopes they can be authoritative for, and they = need access to information for those scopes.  It comes down to = whoever sends control information for a scope needs to know enough to = report for that scope.

So for this example, the = HSSs would need to know that they are authoritative for their hostname = and that it is not being shared with other servers.  They shouldn't = need to know anything else about the topology to use the = destination-host = scope.

Thanks,

Eric


On Jul 14, 2013, at 9:52 , "DOLLY, = MARTIN C" <md3135@att.com> = wrote:

 
Does this assume that the server needs to = have knowledge of the topology to which it is deployed in order to = determine which Scope to send?
 
 
Martin
From: Eric McMurry = [mailto:emcmurry@computer.org] 
Sent: Sunday, July 14, 2013 10:41 = AM
To: DOLLY, = MARTIN C
Cc: dime@ietf.org; Ben Campbell (ben@nostrum.com)
Subject: Re: [Dime] Diameter = Overload - Destination-Host = Scope
Hi = Martin,
I = think this could be one of the most used scopes.  Any time you want = to throttle traffic towards a single server, or a cluster masquerading = as a single server, this would be the go to = scope.
For = example, consider an MME  (mobility management) sending traffic to = a cluster of HSSs (subscriber DBs) where the topology of the HSS cluster = is not hidden.  Let's also assume that the HSSs in the cluster are = responsible for different subscribers, and so may go into overload = independently.  If one of these HSSs goes into overload, it could = then use the destination-host scope towards the MME to request that MME = to reduce traffic that it sends to just that HSS.  Traffic towards = other HSSs would not be affected.
 
Does that make = sense?
On = Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" <md3135@att.com> wrote:


Ben,
 
Can you describe scenarios where Destination-Host = Scope would be used?
 
Thanks,
 
Martin Dolly
Lead Member Technical = Staff
AT&T = Labs
 
DiME@ietf.org
X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Session Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 17:35:35 -0000 I don't think session scope useful for anything other than maybe very = small deployments. If the number of sessions you need to report on at = any one time goes beyond a pretty small number, it will become unwieldy. = I think it's inclusion might even violate our requirements about not = adding significant work to an already overloaded node. The session group = mechanism and associated scope are designed to handle the situation = where you need to report on a large number of fate-shared sessions. The one exception I can think of would be if you have a single (or small = number) of sessions that are generating an inordinate amount of Diameter = traffic. I have trouble imagining a use case that would drive that. Is = that something you see happening? I can imagine a poorly behaved device = causing lots of new session requests, but not lots of requests in the = same session. (Obviously, sending too much user plane traffic can be a = problem, but that shouldn't drive signaling). On Jul 14, 2013, at 7:44 AM, "DOLLY, MARTIN C" wrote: > Ben, > =20 > How useful is the Session Scope? Particularly, when Session-Group = Scope is used? > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 From ben@nostrum.com Sun Jul 14 10:38:44 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 6FCA521F9D8E for ; Sun, 14 Jul 2013 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTN6Yh7LMIkm for ; Sun, 14 Jul 2013 10:38:44 -0700 (PDT) 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 EC1B721F9C85 for ; Sun, 14 Jul 2013 10:38:43 -0700 (PDT) Received: from [10.0.1.12] (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 r6EHcgTg060106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Jul 2013 12:38:42 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Sun, 14 Jul 2013 12:38:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <14603BBA-827C-44B0-AE59-FE0598390B5C@nostrum.com> References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Destination-Realm Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 17:38:44 -0000 Am I correct in assuming we mean mandatory for implementations (i.e. the = existing requirement in the Roach draft), as opposed to the requirement = for protocol support in the requirements draft? If so, I think that's a reasonable work group discussion. I certainly = don't see a need to make it mandatory to _send_. We might need to think = further about whether it's mandatory to _understand_. (This discussion will probably interact with the one from your separate = email about implicit scopes) On Jul 14, 2013, at 7:46 AM, "DOLLY, MARTIN C" wrote: > Ben, > =20 > Does Destination-Realm Scope have to be mandatory? We do not see a use = for it in our network deployment. > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 From ben@nostrum.com Sun Jul 14 10:49:51 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 0259F21F8952 for ; Sun, 14 Jul 2013 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dumjubjy72Q for ; Sun, 14 Jul 2013 10:49:50 -0700 (PDT) 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 613E821F9C16 for ; Sun, 14 Jul 2013 10:49:50 -0700 (PDT) Received: from [10.0.1.12] (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 r6EHnm16061303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Jul 2013 12:49:49 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Sun, 14 Jul 2013 12:49:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 17:49:51 -0000 On Jul 14, 2013, at 7:49 AM, "DOLLY, MARTIN C" wrote: > Ben, > =20 > Is there a need for both Connection and Host Scopes? If so why? I'm on the fence on this one. I think we definitely need Connection. I = have mixed feelings about Host. Many large capacity Diameter implementations are built as clusters of = boxes, or blades on a shelf. In my experience, these clusters often = present themselves as a single Diameter node. This creates situations = where two peers may have many transport connections between them. On the surface, this seems to argue for "Host", since you could = theoretically send a single report on one connection, and have it affect = all connections to that host. It might also have an advantage in = preventing a node from opening new connections to an already overloaded = peer. On the other hand, it's not always easy to know that two different = transport connections actually terminate on the same host. So even if = one were to send a report at the Host scope, one is likely to still need = to send it on all open transport connections. If so, then the advantage = of Host may go away. The Host scope could also imply a need for all of = the blades in a "node" to synchronize their views of peer overload = state. I suspect this may be difficult for some implementations. So I lean towards thinking we need Connection, but that Host may be = redundant. But I would like to hear any arguments to the contrary. From ben@nostrum.com Sun Jul 14 10:56:40 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 63E6621F8437 for ; Sun, 14 Jul 2013 10:56:40 -0700 (PDT) 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.205, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTJXliES1m4P for ; Sun, 14 Jul 2013 10:56:39 -0700 (PDT) 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 3B1E021F99C2 for ; Sun, 14 Jul 2013 10:56:36 -0700 (PDT) Received: from [10.0.1.12] (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 r6EHuUPK062091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Jul 2013 12:56:31 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Sun, 14 Jul 2013 12:56:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <97F8B360-CAAA-481F-8309-016EE99816BD@nostrum.com> References: To: Eric McMurry X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 17:56:40 -0000 On Jul 14, 2013, at 9:40 AM, Eric McMurry wrote: > Hi Martin, >=20 > The main use of DWR/DWA for this would be quiescent connections. Take = a case where an overload condition has caused a server to request a = complete traffic backoff. Once that happens, until the timer on that = overload control information pops, the clients won't send any traffic = for scope encompassed by that backoff request. If that server recovers = before that backoff period, the client will still not send it any = traffic. Using a DWR though, the server can send new control = information at any time, so that it could indicate to the client when it = has recovered, so that traffic can begin flowing. The real use of this = is to ensure that links don't stay quiescent any longer than necessary. = The general difference though between using the watchdog messages vs. = other applications is that they can be sent in an ad hoc fashion without = side effects. I concur with this, but have a couple of additional points: 1) I don't think we want to restrict the sending of _initial_ overload = info to active peers only. Imagine a pair of agents, where clients for = one reason or another send all traffic over one, and use the other as a = backup. If both agents have connections to a server, one of those = connections may be effectively quiescent. If the server sends an = overload report to the active server, clients may simply redirect = traffic to the backup server, and cause that connection to become = suddenly active. 2) The quiescent connection argument assumes that DWR/DWA don't _also_ = get quenched by an overload report. I suspect we never want that to = happen, and should make that explicit somewhere in the solution. >=20 > Thanks, >=20 > Eric >=20 >=20 > On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: >=20 >> Ben, >> =20 >> Everyone agrees that load/overload information needs to be conveyed = in Application level messages. >> =20 >> Under what circumstances is there a benefit conveying the = load/overload information in diameter Connection level messages (e.g., = DRA, DRW)? >> =20 >> Thanks, >> =20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Labs >> md3135@att.com >> +1-609-903-3360 >> =20 >> =20 >> =20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From ben@nostrum.com Sun Jul 14 11:01:32 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 5770821F8F24 for ; Sun, 14 Jul 2013 11:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Ee8NHCeodQ for ; Sun, 14 Jul 2013 11:01:31 -0700 (PDT) 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 A4A4F21F8437 for ; Sun, 14 Jul 2013 11:01:31 -0700 (PDT) Received: from [10.0.1.12] (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 r6EI1QTj062657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Jul 2013 13:01:27 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> Date: Sun, 14 Jul 2013 13:01:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 18:01:32 -0000 On Jul 14, 2013, at 9:41 AM, Eric McMurry wrote: > Hi Martin, >=20 > Technically that should be possible. I have some concern about mixing = implicit and explicit scopes though. That could be confusing. I would = think it won't be that hard to put those two scopes into control = information they apply to.=20 >=20 > Perhaps others have thoughts on mixing implicit and explicit scopes? I think this depends on what we mean by implicit scopes. Is an implicit = scope a default that is used if no scope indicators are in an overload = report? Or is it a scope that is assumed to be in all reports even if = not indicated? I think the first _might_ make sense. The second runs = afoul of your concern about mixing implicit and explicit. In general, though, I lean towards thinking explicit is usually better. = I can see some uses for implicit, for example if an IP address is = obscured by a NAT, a node might not be able to explicitly indicate its = IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >=20 > Thanks! >=20 > Eric >=20 >=20 >=20 >=20 >=20 > On Jul 14, 2013, at 7:52 , "DOLLY, MARTIN C" wrote: >=20 >> Ben, >> =20 >> Is it possible to define a base default =93implicit=94 Scope, where = the Application-ID and the Connection Scopes are mandatory? >> =20 >> We see these two being the minimum to be supported independent of the = deployment scenario. >> =20 >> Thanks, >> =20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Labs >> md3135@att.com >> +1-609-903-3360 >> =20 >> =20 >> =20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From ben@nostrum.com Sun Jul 14 11:05: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 C99B421F9AEE for ; Sun, 14 Jul 2013 11:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phFpmumgFR+l for ; Sun, 14 Jul 2013 11:05:02 -0700 (PDT) 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 DCD3021F9A94 for ; Sun, 14 Jul 2013 11:05:01 -0700 (PDT) Received: from [10.0.1.12] (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 r6EI4vx7062963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Jul 2013 13:04:57 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Sun, 14 Jul 2013 13:04:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8EDD69EB-E826-449F-BFA7-3CBCD8556D00@nostrum.com> References: To: Eric McMurry X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Destination-Host Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 18:05:02 -0000 On Jul 14, 2013, at 10:19 AM, Eric McMurry = wrote: > Hi Martin, >=20 > I think servers will likely be provisioned with knowledge of what = scopes they can be authoritative for, and they need access to = information for those scopes. It comes down to whoever sends control = information for a scope needs to know enough to report for that scope. >=20 > So for this example, the HSSs would need to know that they are = authoritative for their hostname and that it is not being shared with = other servers. They shouldn't need to know anything else about the = topology to use the destination-host scope. >=20 It's also possible that for the HSS to not be a scope authority for = Destination-Host. It could simply use a Connection scoped report to an = agent, and that agent could send another report downstream that = indicates Destination-Host. Basically that would make the agent the = scope-authority, rather than the server. > Thanks, >=20 > Eric >=20 >=20 > On Jul 14, 2013, at 9:52 , "DOLLY, MARTIN C" wrote: >=20 >> Eric, >> =20 >> Does this assume that the server needs to have knowledge of the = topology to which it is deployed in order to determine which Scope to = send? >> =20 >> Thanks, >> =20 >> Martin >> =20 >> From: Eric McMurry [mailto:emcmurry@computer.org]=20 >> Sent: Sunday, July 14, 2013 10:41 AM >> To: DOLLY, MARTIN C >> Cc: dime@ietf.org; Ben Campbell (ben@nostrum.com) >> Subject: Re: [Dime] Diameter Overload - Destination-Host Scope >> =20 >> Hi Martin, >> =20 >> I think this could be one of the most used scopes. Any time you want = to throttle traffic towards a single server, or a cluster masquerading = as a single server, this would be the go to scope. >> =20 >> For example, consider an MME (mobility management) sending traffic = to a cluster of HSSs (subscriber DBs) where the topology of the HSS = cluster is not hidden. Let's also assume that the HSSs in the cluster = are responsible for different subscribers, and so may go into overload = independently. If one of these HSSs goes into overload, it could then = use the destination-host scope towards the MME to request that MME to = reduce traffic that it sends to just that HSS. Traffic towards other = HSSs would not be affected. >> =20 >> Does that make sense? >> =20 >> Thanks, >> =20 >> Eric >> =20 >> =20 >> On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" wrote: >>=20 >>=20 >> Ben, >> =20 >> Can you describe scenarios where Destination-Host Scope would be = used? >> =20 >> Thanks, >> =20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Labs >> md3135@att.com >> +1-609-903-3360 >> =20 >> =20 >> =20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From emcmurry@computer.org Sun Jul 14 13:59:16 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 8856C21F99A2 for ; Sun, 14 Jul 2013 13:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjruXeuZe+Qq for ; Sun, 14 Jul 2013 13:59:08 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id D0A4221F9974 for ; Sun, 14 Jul 2013 13:59:08 -0700 (PDT) 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 1UyTNs-0001bC-Co; Sun, 14 Jul 2013 20:59:08 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id B9AF2A1FCB8; Sun, 14 Jul 2013 15:59:06 -0500 (CDT) 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: U2FsdGVkX1+6u2gMcMxcwaQLwiOcXMquigK8tDn+lwk= 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 ZEzR7RM5QcI8; Sun, 14 Jul 2013 15:59:06 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id AA4E7A1FCAF; Sun, 14 Jul 2013 15:59:06 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Sun, 14 Jul 2013 15:59:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> To: Ben Campbell X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:59:16 -0000 On Jul 14, 2013, at 13:01 , Ben Campbell wrote: > On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >=20 >> Hi Martin, >>=20 >> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>=20 >> Perhaps others have thoughts on mixing implicit and explicit scopes? >=20 > I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >=20 > In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >=20 =20 The "whatever IP you received this request from" concept could be useful = for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. I wonder if that would satisfy the use cases that folks are = thinking of when they bring up implicit scopes? >=20 >>=20 >> Thanks! >>=20 >> Eric >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 14, 2013, at 7:52 , "DOLLY, MARTIN C" wrote: >>=20 >>> Ben, >>>=20 >>> Is it possible to define a base default =93implicit=94 Scope, where = the Application-ID and the Connection Scopes are mandatory? >>>=20 >>> We see these two being the minimum to be supported independent of = the deployment scenario. >>>=20 >>> Thanks, >>>=20 >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Labs >>> md3135@att.com >>> +1-609-903-3360 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From ben@nostrum.com Sun Jul 14 16:04:25 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 AF65B21F9C22 for ; Sun, 14 Jul 2013 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UkKAYpC5w1z for ; Sun, 14 Jul 2013 16:04:24 -0700 (PDT) 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 AE81F21F9C21 for ; Sun, 14 Jul 2013 16:04:24 -0700 (PDT) Received: from [10.0.1.12] (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 r6EN4HIS094451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Jul 2013 18:04:18 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Sun, 14 Jul 2013 18:04:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 23:04:25 -0000 On Jul 14, 2013, at 3:59 PM, Eric McMurry wrote: >=20 > On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >=20 >> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>=20 >>> Hi Martin, >>>=20 >>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>=20 >>> Perhaps others have thoughts on mixing implicit and explicit scopes? >>=20 >> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>=20 >> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>=20 >=20 > The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. I don't think there's any other way to do "connection" to mean anything = but "this connection". I guess we could explicitly name a 5-tuple, but I = suspect that way leads to madness. OTOH, "this application" could just = as easily be named explicitly, so I'm not sure there's a benefit there. > I wonder if that would satisfy the use cases that folks are thinking = of when they bring up implicit scopes? I don't know the answer there--that's why I asked a similar question in = the previous email :-)= From cathy.zhou@huawei.com Sun Jul 14 20:42: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 A9BA021F9D7E for ; Sun, 14 Jul 2013 20:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7RQUYRu52Ak for ; Sun, 14 Jul 2013 20:42:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C697321F9D66 for ; Sun, 14 Jul 2013 20:42:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATL00663; Mon, 15 Jul 2013 03:42:46 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 04:41:45 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 04:42:31 +0100 Received: from SZXEML513-MBS.china.huawei.com ([169.254.8.100]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 11:42:11 +0800 From: "Zhouqian (Cathy)" To: Jouni Korhonen , "DiME@ietf.org" Thread-Topic: [Dime] Call for agenda items for IETF#87 Berlin meeting Thread-Index: AQHOWiblp90UKDdV6Um3QpqQw9deh5k6tLEAgCaQIgCABB/aYA== Date: Mon, 15 Jul 2013 03:42:10 +0000 Message-ID: References: <9A4AC6D9-BDB5-414E-8DF1-7BC42594250A@gmail.com> <6C04FADA-FC2F-4B60-9F0C-1CB04AD356AC@gmail.com> <92DF24A1-E884-46F4-8696-2605D667D17B@gmail.com> In-Reply-To: <92DF24A1-E884-46F4-8696-2605D667D17B@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for agenda items for IETF#87 Berlin meeting 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, 15 Jul 2013 03:42:55 -0000 Dear co-chairs, We have just submitted this draft to DIME working group. And we'd like to a= sk for a 10 minutes slot to present it.=20 Thanks and comments are welcome. =20 >=20 > A new version of I-D, draft-zhou-dime-4over6-provisioning-01.txt > has been successfully submitted by Cathy Zhou and posted to the > IETF repository. >=20 > Filename: draft-zhou-dime-4over6-provisioning > Revision: 01 > Title: Attribute-Value Pairs For Provisioning Customer Equipment > Supporting IPv4-Over-IPv6 Transitional Solutions > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-0 > 1.txt > Status: > http://datatracker.ietf.org/doc/draft-zhou-dime-4over6-provisioning > Htmlized: > http://tools.ietf.org/html/draft-zhou-dime-4over6-provisioning-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-zhou-dime-4over6-provisioning-01 >=20 > Abstract: > During the transition from IPv4 to IPv6, customer equipment may have > to support one of the various transition methods that have been or > are currently being defined for carrying IPv4 packets over IPv6. > Work is currently in progress to enumerate the information that needs > to be provisioned on a customer edge router to support a list of > transition techniques based on tunneling IPv4 in IPv6, with a view to > defining reusable components for a reasonable transition path between > these techniques. To the extent that the provisioning is done > dynamically, AAA support is needed to provide the information to the > network server responsible for passing the information to the > customer equipment. This document specifies Diameter attribute-value > pairs to be used for that purpose. Best Regards, Cathy, Tom and Qiong > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Jouni Korhonen > Sent: Saturday, July 13, 2013 4:37 AM > To: DiME@ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: Re: [Dime] Call for agenda items for IETF#87 Berlin meeting >=20 >=20 >=20 > Just a reminder.. >=20 > - Jouni & Lionel >=20 > On Jun 18, 2013, at 10:43 AM, Jouni Korhonen > wrote: >=20 > > > > Just a reminder. > > > > - Jouni & Lionel > > > > > > On May 26, 2013, at 6:35 PM, Jouni wrote: > > > >> Folks, > >> > >> We have requested for two hour meeting slot. If you feel like > >> presenting your work (be that in the current charter or not), > >> send a request to the co-chairs. Obviously, chartered items > >> will be prioritized over other topics. > >> > >> - Jouni & Lionel > >> > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Mon Jul 15 09:09: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 D0CF221E80D6; Mon, 15 Jul 2013 09:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2FDCLmsDYrS; Mon, 15 Jul 2013 09:09:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64011E8166; Mon, 15 Jul 2013 09:09:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715160910.6665.82885.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:09:10 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:09:11 -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-08.txt Pages : 27 Date : 2013-07-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 4 are not sufficient for this purpose. This document describes the limitations of the existing mechanisms in Section 5. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Mon Jul 15 10:17: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 EB3F211E8105 for ; Mon, 15 Jul 2013 10:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzfo5xaG+qCy for ; Mon, 15 Jul 2013 10:17:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 099A721F9ACA for ; Mon, 15 Jul 2013 10:17:29 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MJSuF-1V1nLA3dEZ-0035bU; Mon, 15 Jul 2013 19:17:28 +0200 From: Hannes Tschofenig Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="Apple-Mail-56-464454807" Date: Mon, 15 Jul 2013 19:17:25 +0200 Message-Id: <99D69AC2-9319-4D36-B6E6-A9A4ECD089CE@gmx.net> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:F13sNAKsPyPwjp719SJHm4e5eH3zeGKGLkNIUH0kZmuHgB+LNfL 1hACIxun95gDvSQDkJnjiDsZ6Fw3Hsj9XL1PSAaxFWTE3L6JmLMFdhHZrB2fcfXSlEziaeE OmIWmeso8IR0whNi1QmgEO9gpqlicYsOePkwdqP72sVnVVlCpL2cqdPAjfm/uVkSQdoMRSp tNPhgHevtmCcUxLNoOjzA== Subject: [Dime] Diameter AVP Level Security 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, 15 Jul 2013 17:17:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-56-464454807 Content-Type: multipart/alternative; boundary=Apple-Mail-55-464454727 --Apple-Mail-55-464454727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 when I gave a presentation at the last IETF meeting about the = requirements draft I got a lot of feedback and it was clear that the = scope of the document wasn't well understood.=20 With version -01 of the document we have tried to incorporate that = feedback:=20 * Rewrote the use case section to highlight the use cases for = protecting AVPs * Added new security requirements (e.g. discovery & policy support) * Rephrased requirements and added further description * Added Kervin Pillay as co-author=20 Please have a look at this new version since it is a major re-write. = Here is the document: = https://datatracker.ietf.org/doc/draft-tschofenig-dime-e2e-sec-req Ciao Hannes PS: I have also refreshed draft-korhonen-dime-e2e-security. Since the = JOSE working group is getting closer to publishing their specs their = work might be something to look at in the near future.=20 --Apple-Mail-55-464454727 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all, 

when I gave a pr= esentation at the last IETF meeting about the requirements = draft I got a lot of feedback and it was clear that the scope of the = document wasn't well understood. 
With version -01 of the = document we have tried to incorporate that = feedback: 

  * Rewrote the use case = section to highlight the use cases for protecting AVPs
  = * Added new security requirements (e.g. discovery & policy = support)
  * Rephrased requirements and added further = description
  * Added Kervin Pillay as = co-author 

Please have a look at this new = version since it is a major re-write. Here is the document: https://datatracker.ietf.org/doc/draft-tschofenig-dime-e2e-sec-req

Ciao
Hannes

PS:=  I have also refreshed draft-korhonen-dime-e2e-security. Since the JOSE working group is = getting closer to publishing their specs their work might be something = to look at in the near future. 

= --Apple-Mail-55-464454727-- --Apple-Mail-56-464454807 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5C6mAAoJEGhJURNOOiAthNIIAKKvhV9smhES8LTuneEDyXQI MxlZx033srUTrUZPq0mjRbpQ8yVT+SLc2pejYI83XDobyyZdZi/4DpHzgLWgb3hR Lf6o2P0YQnvXe4gBMBVhSAosybSszy0B2aB8bEibDOIxDZVYbjV18aUSnNW9n+UW 8E5KTmaGB7xSdo2qq9qldQak81trz96953StTzeXjz0XgPd9LzC2ZGNcvRfHTisL cQwC7f0OBLLoMXJh8e8lowG4ZeSoI32c6JkZ8cxWJ5WKKujpRxvgbJgs0/ztPRQq 1uEQ1W6z7gYOmSAaDLwvq1bq+TrOwZ2LcKHIaxdrOTzaYE3Ur0ZnNqROON/4KCU= =Kedf -----END PGP SIGNATURE----- --Apple-Mail-56-464454807-- From ben@nostrum.com Mon Jul 15 14:55:01 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 D272621E811C for ; Mon, 15 Jul 2013 14:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ-SUB7xgl+Y for ; Mon, 15 Jul 2013 14:55:00 -0700 (PDT) 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 1F84F11E812C for ; Mon, 15 Jul 2013 14:54:57 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-069-027.mycingular.net [166.147.69.27]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6FLstM0055001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Jul 2013 16:54:55 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 16:54:50 -0500 References: <20130715214925.32107.31037.idtracker@ietfa.amsl.com> To: "dime@ietf.org" Message-Id: <4E40661F-FF8C-4EBC-9C3F-CBE29BC1FC72@nostrum.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.69.27 is authenticated by a trusted mechanism) Subject: [Dime] Fwd: New Version Notification for draft-campbell-dime-overload-issues-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:55:01 -0000 Hi Everyone, I just submitted an update to my Diameter overload issues draft. The = changes were mostly about organization and clarification: 1) Switched the section order to emphasize the non-adjacent overload = reporting discussion.=20 2) Gave up on trying to fit the scope types into a taxonomy. That seemed = to create more confusion than clarity in the previous version. 3) Added a scope-type summary table. 4) Various editorial and clarification changes. Thanks! Ben. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-campbell-dime-overload-issues-01.txt > Date: July 15, 2013 4:49:25 PM CDT > To: Ben Campbell >=20 >=20 > A new version of I-D, draft-campbell-dime-overload-issues-01.txt > has been successfully submitted by Ben Campbell and posted to the > IETF repository. >=20 > Filename: draft-campbell-dime-overload-issues > Revision: 01 > Title: Diameter Overload Control Solution Issues > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 20 > URL: = http://www.ietf.org/internet-drafts/draft-campbell-dime-overload-issues-01= .txt > Status: = http://datatracker.ietf.org/doc/draft-campbell-dime-overload-issues > Htmlized: = http://tools.ietf.org/html/draft-campbell-dime-overload-issues-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-dime-overload-issues-01 >=20 > Abstract: > The Diameter Maintenance and Extensions (DIME) working group has > undertaken an "overload control" work item, with the goal of > standardizing a mechanism to allow Diameter nodes to report overload > information among themselves. Requirements currently include, among > others, the need to accurately report the scope of overload > conditions, and the ability to report overload information between > nodes that are not directly connected at the transport layer. These > requirements introduce complex issues. This document describes = those > issues, in the hope that it will assist the working group's decision > process. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From internet-drafts@ietf.org Mon Jul 15 16:05:12 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 F33A921E8174; Mon, 15 Jul 2013 16:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVsX7jgXhpC2; Mon, 15 Jul 2013 16:05:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E44921E818F; Mon, 15 Jul 2013 16:05:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715230511.25143.68159.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 16:05:11 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:05:12 -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-09.txt Pages : 27 Date : 2013-07-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 4 are not sufficient for this purpose. This document describes the limitations of the existing mechanisms in Section 5. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From emcmurry@computer.org Mon Jul 15 16:10:03 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 0768721E813A for ; Mon, 15 Jul 2013 16:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW83CZ1FHALW for ; Mon, 15 Jul 2013 16:09:58 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAC311E8109 for ; Mon, 15 Jul 2013 16:09:58 -0700 (PDT) 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 1Uyru1-000AgV-6V for dime@ietf.org; Mon, 15 Jul 2013 23:09:57 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id C9C89A60BAB for ; Mon, 15 Jul 2013 18:09:56 -0500 (CDT) 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: U2FsdGVkX1+V7fBhMoqFX3nLCOPWZxgQtsXrspt8q/U= 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 NVgDNPlGy0yM for ; Mon, 15 Jul 2013 18:09:56 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id B8AF2A60B97 for ; Mon, 15 Jul 2013 18:09:56 -0500 (CDT) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_BAF3C128-25B0-4616-A3E9-61425EF19FA8" Message-Id: Date: Mon, 15 Jul 2013 18:09:55 -0500 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Dime] update of overload control requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:10:03 -0000 --Apple-Mail=_BAF3C128-25B0-4616-A3E9-61425EF19FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There is an update of the overload control requirements draft: URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-09.txt Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-09 This addresses comments from AD review. The 08 version was an interim = to ensure that the deadline was not missed before Berlin. The 09 = version only has one additional change around the 2119 usage language. Thanks, Eric --Apple-Mail=_BAF3C128-25B0-4616-A3E9-61425EF19FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii There = is an update of the overload control requirements = draft:


This = addresses comments from AD review.  The 08 version was an interim = to ensure that the deadline was not missed before Berlin.  The 09 = version only has one additional change around the 2119 usage = language.

Thanks,

= Eric


= --Apple-Mail=_BAF3C128-25B0-4616-A3E9-61425EF19FA8-- From internet-drafts@ietf.org Mon Jul 15 16:30:48 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 66CB521E81B0; Mon, 15 Jul 2013 16:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzw5vUy7WquL; Mon, 15 Jul 2013 16:30:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F2F11E825F; Mon, 15 Jul 2013 16:30:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715233047.10475.11358.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 16:30:47 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:30:48 -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 Group Signaling Author(s) : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-01.txt Pages : 20 Date : 2013-07-15 Abstract: In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-group-signaling-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-group-signaling-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nh.jones01@gmail.com Mon Jul 15 21:12: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 9ABAD21E80FC for ; Mon, 15 Jul 2013 21:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbH2QMY0x3bM for ; Mon, 15 Jul 2013 21:12:47 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 06D5A21F9CA8 for ; Mon, 15 Jul 2013 21:12:46 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so232878pbb.8 for ; Mon, 15 Jul 2013 21:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:x-priority:x-mailer :mime-version:content-transfer-encoding:content-type; bh=UIXUSh2iGKpAFIze4JPaLgYTQ4OxyE2R0p9f4MMHdio=; b=Bx2BaymiZ4il54EMwfDxaAJbyk4SrhLqsCO7EZFvJa0TXRzJ6kKieNOMlXEIh8eb/W bMw4Z2TxwdL7riWUfHWP1QxXxtjuevVA+TH1wX5vy/lg4uT2thvTxu9i3r3FA+R+Iixe xi+T1jxPQ23D1Bo3ap2rri8NMJVK10K9H49axnkiPlXSKArEg9u00NzMxNVmxH36ETE8 anKSXW+yha72zl3G+756hyFlCKxSRM9cTF8emtwn77yp553wYMzYXc2eWolikTfmWFSK +s6vUnzAZZpxk83t2VtAl0LCk26/OKdFR8qV5ZWHyXmSI2Qt/lx3ZKdHNmIJD4PxmGpO dJww== X-Received: by 10.66.190.101 with SMTP id gp5mr681173pac.19.1373947966782; Mon, 15 Jul 2013 21:12:46 -0700 (PDT) Received: from www.queryhome.com (ec2-54-245-79-134.us-west-2.compute.amazonaws.com. [54.245.79.134]) by mx.google.com with ESMTPSA id i16sm1595708pag.18.2013.07.15.21.12.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 15 Jul 2013 21:12:46 -0700 (PDT) Date: Tue, 16 Jul 2013 04:12:44 +0000 To: dime@ietf.org From: Norah Jones Message-ID: X-Priority: 3 X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Subject: [Dime] Question about Gx over Gy interface in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Norah Jones List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 04:12:47 -0000 Hi, 3GPP 29.210 section 6 talks about Gx over Gy application. My question is about the use case, i.e. in what practical scenario one will require to have Gx over Gy support. Thanks, Norah Jones From hannes.tschofenig@gmx.net Tue Jul 16 00:59:10 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 3E46B11E8245 for ; Tue, 16 Jul 2013 00:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GCWyPVo3Q5z for ; Tue, 16 Jul 2013 00:59:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 19BFB11E8233 for ; Tue, 16 Jul 2013 00:59:03 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfBX6-1UNPIm3boW-00orA7; Tue, 16 Jul 2013 09:58:57 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2013 09:58:53 +0200 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:oNm7vQ1ZwbR6xwl7HmHMEEN2EFj5f4AZ/vbfIEGiYhvqygEam0t 1hx1OeVXAq3qqNUgaj5ElaMR5fGjzTF9FwoiL2jq2RTghKyeWjCcEOt8wrDLOrI1k9JGIG8 lhvYSdLJBJ3YIkxvuFC755kE3o8WecQ0PQ4Bj5wHRqELM5BxS2MGOyVwXT886uqvPTkvYwr I7ryB4aRtBkq6zhZEiqPQ== Subject: [Dime] New Overload Solution Approach 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, 16 Jul 2013 07:59:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 I submitted a new approach for dealing with overload signaling in = Diameter.=20 There are three documents:=20 - ---------- 1) Document with architectural principles and the information model http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt 2) The Diameter Load Balancing Application (DLBA) that specifically = provides the ability to exchange information for load balancing http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt 3) An mechanism to piggyback overload information from the Diameter = server to the Diameter client = http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.tx= t - ---------- Probably the most important question is the following: What motivated me = to write these documents? The answer is pretty simple: I was unhappy = with the complexity introduced by the Tekelec proposal. I wanted to = create a simple foundation that can then be extended on a need-by-need = basis (as we do with other Diameter applications as well). I was = wondering how to simply it.=20 Ciao Hannes PS: There are various reasons for the complexity in the Tekelec solution = proposal. I have captured some of those reasons (but not all) in = draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I = designed this solution approach in a modular fashion. For example, a = deployment may choose not to use the load balancing component (as such = it is optional) in case there is no load balancing between different = servers (for a given Diameter application) or in case load balancing is = accomplished using other techniques. (Needless to say that companies = have used load balancing in Diameter before this work has started.) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5P0+AAoJEGhJURNOOiAtwQwH/AltiRpY0rOx0J4KMRM7ZELn 13mfj4ctQrn8qTDtlS2xE0V40lGPzfstcbaWQiKhVtiZePB1kFusWYUXyhST6p0A grXolprsL4vl+wZifGSkwny62/VJbNkjQ7coiiQrutcInUmXV8IUjsXntK7KjHfX sh6r6pCVLNRwh8SaJzbxogItssb2+StpbDgDvryNFVL9TgYhdg8XMRCN/4RgqP7D QObBw3/TBORrE3RAYmOo/hF3zPf6qiw8bePh51uW7Ve+hgEzYuuxYdByFFlkSEKq sZUUXFMnrEs1sr+uzhLOtg5o9e1z9G78V9Ye1G5it+zU+qoBwdSr6m2/Dzpsqj8=3D =3DdADz -----END PGP SIGNATURE----- From jean-jacques.trottin@alcatel-lucent.com Tue Jul 16 02:11:24 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 A580621E81AD for ; Tue, 16 Jul 2013 02:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFiLYf4eNaJc for ; Tue, 16 Jul 2013 02:11:19 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 11AEF21E80D7 for ; Tue, 16 Jul 2013 02:11:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6G9BAVM003046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 04:11:13 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6G9BAVN026327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 11:11:10 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 11:11:10 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Conveying Load/Overload informatio iin Connection messages Thread-Index: AQHOggRoIpsthcY1ok6dJaZ+/GYf7g== Date: Tue, 16 Jul 2013 09:11:09 +0000 Message-ID: References: <97F8B360-CAAA-481F-8309-016EE99816BD@nostrum.com> In-Reply-To: <97F8B360-CAAA-481F-8309-016EE99816BD@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload informatio iin Connection messages 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, 16 Jul 2013 09:11:24 -0000 Hi About the use of connection messages (DWR/DWA) to convey overload info, I d= o not yet foresee the use of DWR/DWA with overload info - case of quiescent line, this seems quite theoretical, it would mean that = when entering in overload conditions the server would block the whole traff= ic, this is not in line with the objective to maintain an optimal throughpu= t. The server when generating overload info has to avoid to block the whole= traffic=20 - case of active stand-by: in normal conditions (outside overload), a send= ing entity will not send traffic towards a stand by entity, except if the a= ctive receiving entity fails. If a part of traffic is redirected, it is no = more an active / Standby but a load balancing case. Management of this type= of situations (active, stand-by) is handled through other mechanism than t= he use of DWR/DWA with overload info. Best regards JJacques=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: dimanche 14 juillet 2013 19:57 =C0=A0: Eric McMurry Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Diameter Overload - Conveying Load/Overload informatio= n in Connection messages On Jul 14, 2013, at 9:40 AM, Eric McMurry wrote: > Hi Martin, >=20 > The main use of DWR/DWA for this would be quiescent connections. Take a = case where an overload condition has caused a server to request a complete = traffic backoff. Once that happens, until the timer on that overload contr= ol information pops, the clients won't send any traffic for scope encompass= ed by that backoff request. If that server recovers before that backoff pe= riod, the client will still not send it any traffic. Using a DWR though, t= he server can send new control information at any time, so that it could in= dicate to the client when it has recovered, so that traffic can begin flowi= ng. The real use of this is to ensure that links don't stay quiescent any = longer than necessary. The general difference though between using the wat= chdog messages vs. other applications is that they can be sent in an ad hoc= fashion without side effects. I concur with this, but have a couple of additional points: 1) I don't think we want to restrict the sending of _initial_ overload info= to active peers only. Imagine a pair of agents, where clients for one reas= on or another send all traffic over one, and use the other as a backup. If = both agents have connections to a server, one of those connections may be e= ffectively quiescent. If the server sends an overload report to the active = server, clients may simply redirect traffic to the backup server, and cause= that connection to become suddenly active. 2) The quiescent connection argument assumes that DWR/DWA don't _also_ get = quenched by an overload report. I suspect we never want that to happen, and= should make that explicit somewhere in the solution. >=20 > Thanks, >=20 > Eric >=20 >=20 > On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: >=20 >> Ben, >> =20 >> Everyone agrees that load/overload information needs to be conveyed in A= pplication level messages. >> =20 >> Under what circumstances is there a benefit conveying the load/overload= information in diameter Connection level messages (e.g., DRA, DRW)? >> =20 >> Thanks, >> =20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Labs >> md3135@att.com >> +1-609-903-3360 >> =20 >> =20 >> =20 >> _______________________________________________ >> 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 jean-jacques.trottin@alcatel-lucent.com Tue Jul 16 02:12:23 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 01A4921F9A7E for ; Tue, 16 Jul 2013 02:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbRBvEkxUvRz for ; Tue, 16 Jul 2013 02:12:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 801BA21F85F4 for ; Tue, 16 Jul 2013 02:12:17 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6G9CDdD004278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 04:12:15 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6G9CDil027016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 11:12:13 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 11:12:12 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: Ac6AkPt9WmLHlk2/TcKLA1L3YPNX5P///NqAgAA3+YCAADGjAIAAIvkA//2ku2A= Date: Tue, 16 Jul 2013 09:12:12 +0000 Message-ID: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> In-Reply-To: <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 16 Jul 2013 09:12:23 -0000 Hi Ben, Eric and all About the implicit scope, I am thinking to the one used for an overload inf= o which relates to the traffic to which the message transporting this overl= oad info belongs, meaning the traffic between a Destination Host/destinatio= n realm, origin Host/origin realm, for a given Application ID. This scope i= s implicitly defined by these AVPs of the message and does not require a co= mbination of Scope AVPs Another point is on how to limit the number of scopes and their combination= s. Such a number of possibilities increase the complexity of the overload c= ontrol management, which increases the risks. The implicit scope is an answ= er to this question as it can be used instead of the other scopes such as D= estination Host, Origin Host, application ID, connection, and their combina= tions in many cases. Best regards JJacques -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: lundi 15 juillet 2013 01:04 =C0=A0: Eric McMurry Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Diameter Overload - Default "Implicit" Scope On Jul 14, 2013, at 3:59 PM, Eric McMurry wrote: >=20 > On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >=20 >> On Jul 14, 2013, at 9:41 AM, Eric McMurry wrote: >>=20 >>> Hi Martin, >>>=20 >>> Technically that should be possible. I have some concern about mixing = implicit and explicit scopes though. That could be confusing. I would thi= nk it won't be that hard to put those two scopes into control information t= hey apply to.=20 >>>=20 >>> Perhaps others have thoughts on mixing implicit and explicit scopes? >>=20 >> I think this depends on what we mean by implicit scopes. Is an implicit = scope a default that is used if no scope indicators are in an overload repo= rt? Or is it a scope that is assumed to be in all reports even if not indic= ated? I think the first _might_ make sense. The second runs afoul of your c= oncern about mixing implicit and explicit. >>=20 >> In general, though, I lean towards thinking explicit is usually better. = I can see some uses for implicit, for example if an IP address is obscured = by a NAT, a node might not be able to explicitly indicate its IP address to= a peer. But that would be more of an explicit scope indication with an imp= licit value. For example a Host scope with a value of "whatever IP address = you received this request from" >>=20 >=20 > The "whatever IP you received this request from" concept could be useful = for some other scopes also. For example, whatever connection you received = this request on, or whatever application you received this request on. I don't think there's any other way to do "connection" to mean anything but= "this connection". I guess we could explicitly name a 5-tuple, but I suspe= ct that way leads to madness. OTOH, "this application" could just as easily= be named explicitly, so I'm not sure there's a benefit there. > I wonder if that would satisfy the use cases that folks are thinking of = when they bring up implicit scopes? I don't know the answer there--that's why I asked a similar question in the= previous email :-) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jean-jacques.trottin@alcatel-lucent.com Tue Jul 16 02:20: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 AAF3621E80D7 for ; Tue, 16 Jul 2013 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWExiVUi6i38 for ; Tue, 16 Jul 2013 02:20:12 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 35FA121F8BB7 for ; Tue, 16 Jul 2013 02:20:11 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6G9Jqoa013115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 04:19:57 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6G9Jqkl019340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 11:19:52 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 11:19:52 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Session Scope Thread-Index: Ac6Aj9rLa5EEUclpSMaejYEFoX1djAAF+oCAAFdgOfA= Date: Tue, 16 Jul 2013 09:19:51 +0000 Message-ID: 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.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Dime] Diameter Overload - Session Scope 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, 16 Jul 2013 09:20:18 -0000 Hi About Session scope, I agree there is no real use cases, as Ben mentioned, = so we may not consider it at this stage of the analysis. Best regards JJacques=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: dimanche 14 juillet 2013 19:35 =C0=A0: DOLLY, MARTIN C Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Diameter Overload - Session Scope I don't think session scope useful for anything other than maybe very small= deployments. If the number of sessions you need to report on at any one t= ime goes beyond a pretty small number, it will become unwieldy. I think it'= s inclusion might even violate our requirements about not adding significan= t work to an already overloaded node. The session group mechanism and assoc= iated scope are designed to handle the situation where you need to report o= n a large number of fate-shared sessions. The one exception I can think of would be if you have a single (or small nu= mber) of sessions that are generating an inordinate amount of Diameter traf= fic. I have trouble imagining a use case that would drive that. Is that som= ething you see happening? I can imagine a poorly behaved device causing lot= s of new session requests, but not lots of requests in the same session. (O= bviously, sending too much user plane traffic can be a problem, but that sh= ouldn't drive signaling). On Jul 14, 2013, at 7:44 AM, "DOLLY, MARTIN C" wrote: > Ben, > =20 > How useful is the Session Scope? Particularly, when Session-Group Scope i= s used? > =20 > Thanks, > =20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Labs > md3135@att.com > +1-609-903-3360 > =20 > =20 > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jean-jacques.trottin@alcatel-lucent.com Tue Jul 16 02:24:06 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 C80AA21E81C2 for ; Tue, 16 Jul 2013 02:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nViQlPZTZ1-a for ; Tue, 16 Jul 2013 02:24:01 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 792AF21E81C3 for ; Tue, 16 Jul 2013 02:23:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6G9Nu9V015773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 04:23:57 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6G9Ntua023698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 11:23:55 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 11:23:55 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Host vs Connection Scope Thread-Index: Ac6AkIpXn6/NaEbsTKuQr/w6v1YU4AAGTsOAAFcCgrA= Date: Tue, 16 Jul 2013 09:23:55 +0000 Message-ID: References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> In-Reply-To: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 16 Jul 2013 09:24:06 -0000 Hi Ben and all About Host, as Ben, I also think it is redundant. If a cluster is overloade= d, it can send overloaded info on its different connections. I do not see t= he optimisation brought when sending a Host Scope, of which the overload in= fo would apply to all the connections with this Host, compared to sending o= verload info on each of the connections. Best regards JJacques -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: dimanche 14 juillet 2013 19:50 =C0=A0: DOLLY, MARTIN C Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Diameter Overload - Host vs Connection Scope On Jul 14, 2013, at 7:49 AM, "DOLLY, MARTIN C" wrote: > Ben, > =20 > Is there a need for both Connection and Host Scopes? If so why? I'm on the fence on this one. I think we definitely need Connection. I have= mixed feelings about Host. Many large capacity Diameter implementations are built as clusters of boxes= , or blades on a shelf. In my experience, these clusters often present them= selves as a single Diameter node. This creates situations where two peers m= ay have many transport connections between them. On the surface, this seems to argue for "Host", since you could theoretical= ly send a single report on one connection, and have it affect all connectio= ns to that host. It might also have an advantage in preventing a node from = opening new connections to an already overloaded peer. On the other hand, it's not always easy to know that two different transpor= t connections actually terminate on the same host. So even if one were to s= end a report at the Host scope, one is likely to still need to send it on a= ll open transport connections. If so, then the advantage of Host may go aw= ay. The Host scope could also imply a need for all of the blades in a "node= " to synchronize their views of peer overload state. I suspect this may be = difficult for some implementations. So I lean towards thinking we need Connection, but that Host may be redunda= nt. But I would like to hear any arguments to the contrary. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From bclaise@cisco.com Tue Jul 16 02:41:45 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 DF8BD11E8298 for ; Tue, 16 Jul 2013 02:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lz4DLO5djQ3 for ; Tue, 16 Jul 2013 02:41:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4876B11E828E for ; Tue, 16 Jul 2013 02:41:41 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6G9fevX028128; Tue, 16 Jul 2013 11:41:40 +0200 (CEST) Received: from [10.61.209.210] ([10.61.209.210]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6G9fJtR026507; Tue, 16 Jul 2013 11:41:29 +0200 (CEST) Message-ID: <51E5153F.3070101@cisco.com> Date: Tue, 16 Jul 2013 11:41:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dime mailing list Content-Type: multipart/alternative; boundary="------------040203080404020506030907" Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org Subject: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 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, 16 Jul 2013 09:41:46 -0000 This is a multi-part message in MIME format. --------------040203080404020506030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Thanks for the two new draft version. I still see two issues. 1. 1.2 . Causes of Overload Overload occurs when an element, such as a Diameter server or agent, has insufficient resources to successfully process all of the traffic _it is receiving_. ... External resources can include upstream Diameter nodes; for example, a Diameter agent can become effectively overloaded if one or more upstream nodes are overloaded. While overload is not the same thing as network congestion, network congestion can reduce a Diameter nodes ability to process and respond to requests, thus contributing to overload. I'm not discussing whether or not bandwidth is an overload cause, I note a discrepancy in the definition. "A Diameter [RFC6733] node is said to be overloaded when it has insufficient resources to successfully process all of the Diameter requests that it receives." If there is not enough bandwidth, the application-layer Diameter node doesn't receive the Diameter requests. Therefore, it is not overloaded. Now, there is a difference if you start to speak about a system overload (for the lack of a better term) where the system is composed of client and server. In that case, the "system" contains the link, and the bandwidth limitation is a valid cause of system overload. I hope I explained myself correctly. 2. We discussed this text, and it seems that you forgot to include it. A element communicating via protocols other than Diameter that is also using a Diameter application needs to be able to signal to Diameter peers that it is experiencing overload regardless of the cause of the overload, since the overload will affect that element's ability to process Diameter transactions. The element may also need to signal this on other protocols depending on its function and the architecture of the network and application it is providing services for. Whether that is necessary can only be decided within the context of that architecture and application. Proposal: An element that doesn't use Diameter exclusively needs to be able to signal to Diameter peers that it is experiencing overload regardless of the cause of the overload, since the overload will affect that element's ability to process Diameter transactions. If the element communicates with other protocols than Diameter, it may also need to signal the overload situation on these protocols depending on its function and the architecture of the network and application it is providing services for. Whether that is necessary can only be decided within the context of that architecture and use cases. Answer: I like your language in general and propose we incorporate it. We had intended "application" to mean "an application (or use) of Diameter" rather than a "Diameter application", which seem to have unfortunately distinct meanings--better to avoid it entirely. Regards, Benoit --------------040203080404020506030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Dear authors,

Thanks for the two new draft version.

I still see two issues.

1.

1.2.  Causes of Overload
   Overload occurs when an element, such as a Diameter server or agent,
   has insufficient resources to successfully process all of the traffic
   it is receiving.

   ...

   External resources can include upstream Diameter nodes; for example,
   a Diameter agent can become effectively overloaded if one or more
   upstream nodes are overloaded.  While overload is not the same thing
   as network congestion, network congestion can reduce a Diameter nodes
   ability to process and respond to requests, thus contributing to
   overload.


I'm not discussing whether or not bandwidth is an overload cause, I note 
a discrepancy in the definition.

 "A Diameter [RFC6733] node is said to be overloaded when it has 
insufficient resources to successfully process all of the Diameter 
requests that it receives."

If there is not enough bandwidth, the application-layer Diameter node 
doesn't receive the Diameter requests. Therefore, it is not overloaded.

Now, there is a difference if you start to speak about a system overload 
(for the lack of a better term) where the system is composed of client 
and server. In that case, the "system" contains the link, and the 
bandwidth limitation is a valid cause of system overload.

I hope I explained myself correctly.


2.
We discussed this text, and it seems that you forgot to include it.

    A element communicating via protocols other than Diameter that is
    also using a Diameter application needs to be able to signal to
    Diameter peers that it is experiencing overload regardless of the
    cause of the overload, since the overload will affect that element's
    ability to process Diameter transactions.
    The element may also need
    to signal this on other protocols depending on its function and the
    architecture of the network and application it is providing services
    for.  Whether that is necessary can only be decided within the
    context of that architecture and application.

Proposal: An element that doesn't use Diameter exclusively
    needs to be able to signal to  Diameter peers that it is experiencing overload
    regardless of the cause of the overload, since the overload will affect that element's
    ability to process Diameter transactions. If the element communicates
    with other protocols than Diameter, it may also need
    to signal the overload situation on these protocols depending on its function and the
    architecture of the network and application it is providing services
    for.  Whether that is necessary can only be decided within the
    context of that architecture and use cases.

Answer: I like your language in general and propose we incorporate it.  We had intended "application" to mean "an application (or use) of Diameter" rather than a "Diameter application", which seem to have unfortunately distinct meanings--better to avoid it entirely.

Regards, Benoit
--------------040203080404020506030907-- From hannes.tschofenig@gmx.net Tue Jul 16 02:51: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 939B811E8276 for ; Tue, 16 Jul 2013 02:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGVtReh8e8hC for ; Tue, 16 Jul 2013 02:51:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id DA66C11E828E for ; Tue, 16 Jul 2013 02:51:42 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LcBBl-1UFp841nKH-00jcA1 for ; Tue, 16 Jul 2013 11:51:41 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2013 11:51:38 +0200 Message-Id: <3C427782-8E0B-4A38-B2BE-F0C594FE4800@gmx.net> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:sCBBwceEbBaSCg9F+Zz9Pt8ItYYLFjm/B8008/nMd9z9o2kGm8S pvsPkt+4IYnBxb5eMXR5TXU1MSxkEfFGaBsIZGOz5tzkke31GyFhIn3GSZiIDoBgmORV3f2 nd6Kb403RYQJj9O72C989vSYynyF+ocBGQKoZ10V31IAbdLOFvIYUFnOxXX3v6XMsgnYCsx Scj0v/S7GxLBo5ZgPEp5A== Cc: dime@ietf.org Subject: [Dime] Load Balancing vs. Request Rejection 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, 16 Jul 2013 09:51:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Jean Jacques,=20 I noticed that in discussions that two concepts get mixed together, = namely conveying load information for load balancing and overload = information for subsequently rejecting requests.=20 In most cases what you would like to do is to keep load balancing within = your own domain. In most cases a Diameter client does not even get to = see whether you have one or multiple servers when it starts to send a = request. All it gets to see is a single entry point.=20 Passing load information that is useful for load balancing outside your = own realm is 't particularly helpful because what should others do with = that information? External nodes cannot easily (and should not) decide = about which host they want to send their requests to. Do you expect information used for load balancing to be distribute = outside your own realm?=20 With load balancing you can easily have a situation where one server = suddenly cannot receive any further requests because one essential = resource becomes unavailable, such as a connection to a database. Your = active stand-by case is very similar.=20 Overload information is, however, different since it is an optimization = to what has been originally specified in the Diameter Base protocol. It = allows the Diameter client to reject a portion of the requests = independently. The question there is how much effort do you want to = spend to optimize the protocol? How much do you want to optimize?=20 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5RerAAoJEGhJURNOOiAthsoH/3pkBeYgikgZk019tzz88jGi DAm03uKD5lbtoeUaA18hFJCgHnA1wwYiMSvkkbf0+YmNJCK4WJOtxAzHhnmJS28e 4dvVuyeIMHDB6Hsh5PCji4blJjmGn21TQswehEZBBD/bTCAzz/Og15+BTS7h2Ee7 LN+LhoR7uY23PZYxXe8FhlP1O5mDwuukNt2Wm4JLpm+Qq4FJrfYXA9sq9oNs15NG og4CmhCm4SpFMRxTW1Au/UvYwguTrWzRxPQuirEpSDeMphKsllRGpN6B7PsGXQbt vH8HPpFJ7UwK6aHfy2lhyhX3TFE+GUysZUEQs2wwsalElyz0RHaGje7iGWx0beg=3D =3DKfXt -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Tue Jul 16 03:01:38 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 CB19C21F9C72 for ; Tue, 16 Jul 2013 03:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKBAkxwP7xfj for ; Tue, 16 Jul 2013 03:01:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93121F9D71 for ; Tue, 16 Jul 2013 03:01:33 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MF5FT-1Ux7Jf3C4h-00GMK2 for ; Tue, 16 Jul 2013 12:01:32 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2013 12:01:31 +0200 Message-Id: <7EC542C4-968A-4BE9-9998-CE69AF176BD9@gmx.net> To: MARTIN C DOLLY Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:RgnYvUa7wyZdHCfB56c3c5D742YbRhD4etQH3FTM73InnJkRe1l dNOURPq6Rvxy2tk1960hXMmNn9HDDLBjjIwiSdj7oJrxbf+TcJtkK1/xJsIoohlQVB4zu0p 92U6gmJYDeswRo9d8HFcqBiAtj7TYiD8Sg2nFL246LEkeqc2JI0AP6r5mIWV8x2K/uTiqsu 7nk/mRX1BH3FGUmKiQTtw== Cc: dime@ietf.org Subject: [Dime] Questions about the anticipated deployment of the Diameter Overload 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, 16 Jul 2013 10:01:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Martin,=20 you raised a couple of questions on the list and you seem to have an = opinion about the outcome of the work. Let me ask you a couple of questions:=20 * Do you expect Diameter clients to be updated to process overload = information to relay the error messages to the end points?=20 * Do you expect overload situations in Diameter agents (like proxies) or = only with Diameter servers?=20 * Do you expect Diameter server load information used for load = balancing (not overload information) to stay within the AT&T network? * Can you explain the load balancing scenario you expect to deploy? Do = you have Diameter relays between the load balancer and the Diameter = servers?=20 * What information about your internal Diameter infrastructure do you = expect to be visible to the outside world (to other Diameter nodes)? Ciao Hannes =20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5Rn7AAoJEGhJURNOOiAtyScIAJ4AJkH2FkNZG9dctqtcgrRm M+Nn6NCwaTpIRIpmgfk6NAhMXM78YLz7bJRdwHYiU8KPhgzm2XwV/SOXnVwmSPQ8 h/h9fvppHM7cJKKFynrlKaoB0QDA7y8CbLoTtCBJleYaTUC/kPqsVF/yLXK5oaAy T79YCctkQKUQvym8tj79+lFfb86+GQZ/ZuZHnikGYrQ8DVo2bAr7UDXf3O5jJFQ7 Ry9HovGrarJHbCwaIOMuQ16GDipQ3bVSdurWboRNovMEhF+kczBbUHz5gfISH0SU dfGKa17TEKY4OhzL0UGYUmJUltjImK4Vpu25Bh1NFqfh0Ld/Zaw1rVfFgPWCjYk=3D =3DlTJZ -----END PGP SIGNATURE----- From Marco.Liebsch@neclab.eu Tue Jul 16 03:41:21 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 CDC9D21E8053 for ; Tue, 16 Jul 2013 03:41:21 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZu8MKijjQYA for ; Tue, 16 Jul 2013 03:41:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4111E80AE for ; Tue, 16 Jul 2013 03:41:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 98339104B58 for ; Tue, 16 Jul 2013 12:40:40 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i-F+R4YjDpe for ; Tue, 16 Jul 2013 12:40:40 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7E726104B57 for ; Tue, 16 Jul 2013 12:40:35 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 16 Jul 2013 12:39:42 +0200 From: Marco Liebsch To: "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-group-signaling-01.txt Thread-Index: AQHOgbNwAd31hAi+Pka+WDc99+gWuZlnHHnA Date: Tue, 16 Jul 2013 10:39:41 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D55308DFC@DAPHNIS.office.hd> References: <20130715233047.10475.11358.idtracker@ietfa.amsl.com> In-Reply-To: <20130715233047.10475.11358.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] FW: I-D Action: draft-ietf-dime-group-signaling-01.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, 16 Jul 2013 10:41:21 -0000 We posted an updated WG draft about Diameter group signaling. This revision has the current WG view adopted on how existing CCFs can be re-used to enable session grouping and to format Diameter group commands. Your comments are appreciated. Intention is to converge on the mechanisms and some more details during the Berlin meeting. marco -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Dienstag, 16. Juli 2013 01:31 To: i-d-announce@ietf.org Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-01.txt 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 Group Signaling Author(s) : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-01.txt Pages : 20 Date : 2013-07-15 Abstract: In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-group-signaling-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-group-signaling-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Tue Jul 16 04:48:31 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 0746D11E8195 for ; Tue, 16 Jul 2013 04:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJWhJ5sjT-ws for ; Tue, 16 Jul 2013 04:48:26 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1C611E8276 for ; Tue, 16 Jul 2013 04:48:25 -0700 (PDT) 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 1Uz3k1-0000sv-Fz; Tue, 16 Jul 2013 11:48:25 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 73A15A7F1F9; Tue, 16 Jul 2013 06:48:23 -0500 (CDT) 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: U2FsdGVkX1/VlFbpDWZQTqqBrZ/00LXBDer9D5xmsJ4= 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 kBPWcS5fSq4Z; Tue, 16 Jul 2013 06:48:17 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 3AF84A7F1DC; Tue, 16 Jul 2013 06:48:17 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Tue, 16 Jul 2013 06:48:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <767D47DF-E98E-460D-B110-66A4FFCDAD1C@computer.org> References: <97F8B360-CAAA-481F-8309-016EE99816BD@nostrum.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload informatio iin Connection messages 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, 16 Jul 2013 11:48:31 -0000 Hi JJacques, On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi >=20 > About the use of connection messages (DWR/DWA) to convey overload = info, I do not yet foresee the use of DWR/DWA with overload info >=20 > - case of quiescent line, this seems quite theoretical, it would mean = that when entering in overload conditions the server would block the = whole traffic, this is not in line with the objective to maintain an = optimal throughput. The server when generating overload info has to = avoid to block the whole traffic=20 I agree that things have gone badly if this happens. I'm not sure about = it being theoretical though. A server may chose to throttle some = clients more than others and things do go rather badly on occasion. = Hopefully this mechanism would help keep things from getting to this = point in most situations. >=20 > - case of active stand-by: in normal conditions (outside overload), a = sending entity will not send traffic towards a stand by entity, except = if the active receiving entity fails. If a part of traffic is = redirected, it is no more an active / Standby but a load balancing case. = Management of this type of situations (active, stand-by) is handled = through other mechanism than the use of DWR/DWA with overload info. >=20 The case for the backup being able to pick up the traffic falls down if = the active was reporting overload because of some resource that was = shared by both it and the backup. Sending traffic to the backup will = result in more overload then. Is there a side effect of allowing overload control information on = watchdogs that is undesirable? Thanks! Eric > Best regards >=20 > JJacques=20 >=20 >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : dimanche 14 juillet 2013 19:57 > =C0 : Eric McMurry > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload = information in Connection messages >=20 >=20 > On Jul 14, 2013, at 9:40 AM, Eric McMurry = wrote: >=20 >> Hi Martin, >>=20 >> The main use of DWR/DWA for this would be quiescent connections. = Take a case where an overload condition has caused a server to request a = complete traffic backoff. Once that happens, until the timer on that = overload control information pops, the clients won't send any traffic = for scope encompassed by that backoff request. If that server recovers = before that backoff period, the client will still not send it any = traffic. Using a DWR though, the server can send new control = information at any time, so that it could indicate to the client when it = has recovered, so that traffic can begin flowing. The real use of this = is to ensure that links don't stay quiescent any longer than necessary. = The general difference though between using the watchdog messages vs. = other applications is that they can be sent in an ad hoc fashion without = side effects. >=20 > I concur with this, but have a couple of additional points: >=20 > 1) I don't think we want to restrict the sending of _initial_ overload = info to active peers only. Imagine a pair of agents, where clients for = one reason or another send all traffic over one, and use the other as a = backup. If both agents have connections to a server, one of those = connections may be effectively quiescent. If the server sends an = overload report to the active server, clients may simply redirect = traffic to the backup server, and cause that connection to become = suddenly active. >=20 > 2) The quiescent connection argument assumes that DWR/DWA don't _also_ = get quenched by an overload report. I suspect we never want that to = happen, and should make that explicit somewhere in the solution. >=20 >=20 >=20 >>=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >> On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: >>=20 >>> Ben, >>>=20 >>> Everyone agrees that load/overload information needs to be conveyed = in Application level messages. >>>=20 >>> Under what circumstances is there a benefit conveying the = load/overload information in diameter Connection level messages (e.g., = DRA, DRW)? >>>=20 >>> Thanks, >>>=20 >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Labs >>> md3135@att.com >>> +1-609-903-3360 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Tue Jul 16 04:51: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 F25DE21E8198 for ; Tue, 16 Jul 2013 04:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALzrRW5XfN+y for ; Tue, 16 Jul 2013 04:50:57 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 609AA21E80F2 for ; Tue, 16 Jul 2013 04:50:56 -0700 (PDT) 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 1Uz3mR-0002H0-RU; Tue, 16 Jul 2013 11:50:56 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 7B94EA7F39D; Tue, 16 Jul 2013 06:50:55 -0500 (CDT) 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: U2FsdGVkX1/0HceWyOgsiNDAS3tnlAPhWuPDisIPxkI= 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 GZP6t-YHX3HI; Tue, 16 Jul 2013 06:50:55 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 19EC9A7F38E; Tue, 16 Jul 2013 06:50:55 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Tue, 16 Jul 2013 06:50:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 16 Jul 2013 11:51:02 -0000 Hi JJaques, The optimization comes into play when there are a large number of = connections between elements. However, it may still be difficult to = use, for the reasons that Ben outlined. So, I tend to agree that at a = minimum it shouldn't be mandatory and may not be useful. I'm curious if others have counterpoints where they think they would use = this scope. Thanks, Eric On Jul 16, 2013, at 4:23 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi Ben and all >=20 >=20 > About Host, as Ben, I also think it is redundant. If a cluster is = overloaded, it can send overloaded info on its different connections. I = do not see the optimisation brought when sending a Host Scope, of which = the overload info would apply to all the connections with this Host, = compared to sending overload info on each of the connections. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : dimanche 14 juillet 2013 19:50 > =C0 : DOLLY, MARTIN C > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Overload - Host vs Connection Scope >=20 > On Jul 14, 2013, at 7:49 AM, "DOLLY, MARTIN C" wrote: >=20 >> Ben, >>=20 >> Is there a need for both Connection and Host Scopes? If so why? >=20 > I'm on the fence on this one. I think we definitely need Connection. I = have mixed feelings about Host. >=20 > Many large capacity Diameter implementations are built as clusters of = boxes, or blades on a shelf. In my experience, these clusters often = present themselves as a single Diameter node. This creates situations = where two peers may have many transport connections between them. >=20 > On the surface, this seems to argue for "Host", since you could = theoretically send a single report on one connection, and have it affect = all connections to that host. It might also have an advantage in = preventing a node from opening new connections to an already overloaded = peer. >=20 > On the other hand, it's not always easy to know that two different = transport connections actually terminate on the same host. So even if = one were to send a report at the Host scope, one is likely to still need = to send it on all open transport connections. If so, then the advantage = of Host may go away. The Host scope could also imply a need for all of = the blades in a "node" to synchronize their views of peer overload = state. I suspect this may be difficult for some implementations. >=20 > So I lean towards thinking we need Connection, but that Host may be = redundant. But I would like to hear any arguments to the contrary. >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Tue Jul 16 06:28:19 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 0BD6511E80E9 for ; Tue, 16 Jul 2013 06:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLgAErp3HfwD for ; Tue, 16 Jul 2013 06:28:14 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2A03A21F91CE for ; Tue, 16 Jul 2013 06:28:13 -0700 (PDT) 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 1Uz5Ib-00090N-FD; Tue, 16 Jul 2013 13:28:13 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 4BBCCA83680; Tue, 16 Jul 2013 08:28:11 -0500 (CDT) 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: U2FsdGVkX1+kEMQfU+j9YheMmo+ADVp+B0EUtSFK51o= 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 pXsseOKc5SLD; Tue, 16 Jul 2013 08:28:11 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 1D786A8366B; Tue, 16 Jul 2013 08:28:11 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF1B29E-9C1A-4754-B675-9A4415C4B280" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <51E5153F.3070101@cisco.com> Date: Tue, 16 Jul 2013 08:28:10 -0500 Message-Id: <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> References: <51E5153F.3070101@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, dime mailing list Subject: Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 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, 16 Jul 2013 13:28:19 -0000 --Apple-Mail=_4CF1B29E-9C1A-4754-B675-9A4415C4B280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks Benoit, Comments inline. Eric On Jul 16, 2013, at 4:41 , Benoit Claise wrote: > Dear authors, >=20 > Thanks for the two new draft version. >=20 > I still see two issues. >=20 > 1. > 1.2. Causes of Overload >=20 > Overload occurs when an element, such as a Diameter server or = agent, > has insufficient resources to successfully process all of the = traffic > it is receiving. >=20 > ... >=20 > External resources can include upstream Diameter nodes; for = example, > a Diameter agent can become effectively overloaded if one or more > upstream nodes are overloaded. While overload is not the same = thing > as network congestion, network congestion can reduce a Diameter = nodes > ability to process and respond to requests, thus contributing to > overload. >=20 >=20 > I'm not discussing whether or not bandwidth is an overload cause, I = note=20 > a discrepancy in the definition. >=20 > "A Diameter [RFC6733] node is said to be overloaded when it has=20 > insufficient resources to successfully process all of the Diameter=20 > requests that it receives." >=20 > If there is not enough bandwidth, the application-layer Diameter node=20= > doesn't receive the Diameter requests. Therefore, it is not = overloaded. >=20 > Now, there is a difference if you start to speak about a system = overload=20 > (for the lack of a better term) where the system is composed of client=20= > and server. In that case, the "system" contains the link, and the=20 > bandwidth limitation is a valid cause of system overload. >=20 > I hope I explained myself correctly. ah, thanks for catching that. Ben and I had been discussing this but I = see responding to it was lost in the shuffle. My apologies. The definition uses the term resources, which could include a number of = things. For the case where insufficient bandwidth would prevent = overload, I think that would only be true for a very simple topology. = With multiple connections to multiple elements, agents, shared backend = resources, or any other more complex topologies, bandwidth issues could = indeed manifest into overload issues that meet the definition. I suspect that I am not understanding your point fully though. Perhaps = Ben can take a stab if I am not making sense. >=20 >=20 > 2. > We discussed this text, and it seems that you forgot to include it. >=20 > A element communicating via protocols other than Diameter that is=20= > also using a Diameter application needs to be able to signal to=20 > Diameter peers that it is experiencing overload regardless of the=20= > cause of the overload, since the overload will affect that = element's=20 > ability to process Diameter transactions.=20 > The element may also need=20 > to signal this on other protocols depending on its function and = the=20 > architecture of the network and application it is providing = services=20 > for. Whether that is necessary can only be decided within the=20 > context of that architecture and application.=20 >=20 > Proposal: An element that doesn't use Diameter exclusively=20 > needs to be able to signal to Diameter peers that it is = experiencing overload=20 > regardless of the cause of the overload, since the overload will = affect that element's=20 > ability to process Diameter transactions. If the element = communicates=20 > with other protocols than Diameter, it may also need=20 > to signal the overload situation on these protocols depending on = its function and the=20 > architecture of the network and application it is providing = services=20 > for. Whether that is necessary can only be decided within the=20 > context of that architecture and use cases.=20 >=20 > Answer: I like your language in general and propose we incorporate it. = We had intended "application" to mean "an application (or use) of = Diameter" rather than a "Diameter application", which seem to have = unfortunately distinct meanings--better to avoid it entirely. not sure how I missed that, but also my fault. Thanks for catching. I = will fix that for the 10 version to be submitted as soon as the embargo = lifts. >=20 > Regards, Benoit > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_4CF1B29E-9C1A-4754-B675-9A4415C4B280 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Thanks Benoit,

Comments inline.

Eric


On Jul 16, 2013, at 4:41 , Benoit Claise <bclaise@cisco.com> wrote:

Dear authors,

Thanks for the two new draft version.

I still see two issues.

1.

1.2.  Causes of Overload
   Overload occurs when an element, such as a Diameter server or agent,
   has insufficient resources to successfully process all of the traffic
   it is receiving.

   ...

   External resources can include upstream Diameter nodes; for example,
   a Diameter agent can become effectively overloaded if one or more
   upstream nodes are overloaded.  While overload is not the same thing
   as network congestion, network congestion can reduce a Diameter nodes
   ability to process and respond to requests, thus contributing to
   overload.


I'm not discussing whether or not bandwidth is an overload cause, I note 
a discrepancy in the definition.

 "A Diameter [RFC6733] node is said to be overloaded when it has 
insufficient resources to successfully process all of the Diameter 
requests that it receives."

If there is not enough bandwidth, the application-layer Diameter node 
doesn't receive the Diameter requests. Therefore, it is not overloaded.

Now, there is a difference if you start to speak about a system overload 
(for the lack of a better term) where the system is composed of client 
and server. In that case, the "system" contains the link, and the 
bandwidth limitation is a valid cause of system overload.

I hope I explained myself correctly.

ah, thanks for catching that.  Ben and I had been discussing this but I see responding to it was lost in the shuffle.  My apologies.

The definition uses the term resources, which could include a number of things.  For the case where insufficient bandwidth would prevent overload, I think that would only be true for a very simple topology.  With multiple connections to multiple elements, agents, shared backend resources, or any other more complex topologies, bandwidth issues could indeed manifest into overload issues that meet the definition.

I suspect that I am not understanding your point fully though.  Perhaps Ben can take a stab if I am not making sense.



2.
We discussed this text, and it seems that you forgot to include it.

    A element communicating via protocols other than Diameter that is
    also using a Diameter application needs to be able to signal to
    Diameter peers that it is experiencing overload regardless of the
    cause of the overload, since the overload will affect that element's
    ability to process Diameter transactions.
    The element may also need
    to signal this on other protocols depending on its function and the
    architecture of the network and application it is providing services
    for.  Whether that is necessary can only be decided within the
    context of that architecture and application.

Proposal: An element that doesn't use Diameter exclusively
    needs to be able to signal to  Diameter peers that it is experiencing overload
    regardless of the cause of the overload, since the overload will affect that element's
    ability to process Diameter transactions. If the element communicates
    with other protocols than Diameter, it may also need
    to signal the overload situation on these protocols depending on its function and the
    architecture of the network and application it is providing services
    for.  Whether that is necessary can only be decided within the
    context of that architecture and use cases.

Answer: I like your language in general and propose we incorporate it.  We had intended "application" to mean "an application (or use) of Diameter" rather than a "Diameter application", which seem to have unfortunately distinct meanings--better to avoid it entirely.

not sure how I missed that, but also my fault.  Thanks for catching.  I will fix that for the 10 version to be submitted as soon as the embargo lifts.



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

--Apple-Mail=_4CF1B29E-9C1A-4754-B675-9A4415C4B280-- From srdonovan@usdonovans.com Tue Jul 16 07:09: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 0AEED11E80DF for ; Tue, 16 Jul 2013 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YAKKbDrXp0V for ; Tue, 16 Jul 2013 07:09:44 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id D501111E80C5 for ; Tue, 16 Jul 2013 07:09:44 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65262 helo=[192.168.1.146]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uz5wY-0000qe-PU; Tue, 16 Jul 2013 07:09:42 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Steve Donovan In-Reply-To: <767D47DF-E98E-460D-B110-66A4FFCDAD1C@computer.org> Date: Tue, 16 Jul 2013 09:09:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <17F0E2AB-B79E-4E5C-A303-9F5C01DD0705@usdonovans.com> References: <97F8B360-CAAA-481F-8309-016EE99816BD@nostrum.com> <767D47DF-E98E-460D-B110-66A4FFCDAD1C@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan+usdonovans.com/only user confirmed/virtual account not confirmed Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload informatio iin Connection messages 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, 16 Jul 2013 14:09:50 -0000 The active/standby scenario that would support the use of DWR/DWA is = overload followed by failure of the active connection. It would be best = of the standby connection understood the overload state of the peer = prior to becoming active so as to avoid contributing to the overload = situation. DWR/DWA is one way to address this situation. Use of the Host scope = would be another. Steve On Jul 16, 2013, at 6:48 AM, Eric McMurry wrote: > Hi JJacques, >=20 >=20 > On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >> Hi >>=20 >> About the use of connection messages (DWR/DWA) to convey overload = info, I do not yet foresee the use of DWR/DWA with overload info >>=20 >> - case of quiescent line, this seems quite theoretical, it would mean = that when entering in overload conditions the server would block the = whole traffic, this is not in line with the objective to maintain an = optimal throughput. The server when generating overload info has to = avoid to block the whole traffic=20 >=20 > I agree that things have gone badly if this happens. I'm not sure = about it being theoretical though. A server may chose to throttle some = clients more than others and things do go rather badly on occasion. = Hopefully this mechanism would help keep things from getting to this = point in most situations. >=20 >=20 >>=20 >> - case of active stand-by: in normal conditions (outside overload), = a sending entity will not send traffic towards a stand by entity, except = if the active receiving entity fails. If a part of traffic is = redirected, it is no more an active / Standby but a load balancing case. = Management of this type of situations (active, stand-by) is handled = through other mechanism than the use of DWR/DWA with overload info. >>=20 >=20 > The case for the backup being able to pick up the traffic falls down = if the active was reporting overload because of some resource that was = shared by both it and the backup. Sending traffic to the backup will = result in more overload then. >=20 >=20 >=20 > Is there a side effect of allowing overload control information on = watchdogs that is undesirable? >=20 >=20 > Thanks! >=20 > Eric >=20 >=20 >=20 >> Best regards >>=20 >> JJacques=20 >>=20 >>=20 >>=20 >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell >> Envoy=E9 : dimanche 14 juillet 2013 19:57 >> =C0 : Eric McMurry >> Cc : dime@ietf.org >> Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload = information in Connection messages >>=20 >>=20 >> On Jul 14, 2013, at 9:40 AM, Eric McMurry = wrote: >>=20 >>> Hi Martin, >>>=20 >>> The main use of DWR/DWA for this would be quiescent connections. = Take a case where an overload condition has caused a server to request a = complete traffic backoff. Once that happens, until the timer on that = overload control information pops, the clients won't send any traffic = for scope encompassed by that backoff request. If that server recovers = before that backoff period, the client will still not send it any = traffic. Using a DWR though, the server can send new control = information at any time, so that it could indicate to the client when it = has recovered, so that traffic can begin flowing. The real use of this = is to ensure that links don't stay quiescent any longer than necessary. = The general difference though between using the watchdog messages vs. = other applications is that they can be sent in an ad hoc fashion without = side effects. >>=20 >> I concur with this, but have a couple of additional points: >>=20 >> 1) I don't think we want to restrict the sending of _initial_ = overload info to active peers only. Imagine a pair of agents, where = clients for one reason or another send all traffic over one, and use the = other as a backup. If both agents have connections to a server, one of = those connections may be effectively quiescent. If the server sends an = overload report to the active server, clients may simply redirect = traffic to the backup server, and cause that connection to become = suddenly active. >>=20 >> 2) The quiescent connection argument assumes that DWR/DWA don't = _also_ get quenched by an overload report. I suspect we never want that = to happen, and should make that explicit somewhere in the solution. >>=20 >>=20 >>=20 >>>=20 >>> Thanks, >>>=20 >>> Eric >>>=20 >>>=20 >>> On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: >>>=20 >>>> Ben, >>>>=20 >>>> Everyone agrees that load/overload information needs to be conveyed = in Application level messages. >>>>=20 >>>> Under what circumstances is there a benefit conveying the = load/overload information in diameter Connection level messages (e.g., = DRA, DRW)? >>>>=20 >>>> Thanks, >>>>=20 >>>> Martin Dolly >>>> Lead Member Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T Labs >>>> md3135@att.com >>>> +1-609-903-3360 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From isj-dime@i1.dk Tue Jul 16 08:17:44 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 83F9721F9A81 for ; Tue, 16 Jul 2013 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZYh4gDkLBcU for ; Tue, 16 Jul 2013 08:17:44 -0700 (PDT) Received: from i1.dk (isjsys5-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:20d:93ff:fe73:ac12]) by ietfa.amsl.com (Postfix) with ESMTP id 90F9A21F9A14 for ; Tue, 16 Jul 2013 08:17:43 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id CCE1F5C008E for ; Tue, 16 Jul 2013 17:17:38 +0200 (CEST) Received: from isjsys.int.i1.dk (unknown [IPv6:2001:16d8:dd31:1:e00f:c2c4:e0ec:26c]) by i1.dk (Postfix) with ESMTP for ; Tue, 16 Jul 2013 17:17:38 +0200 (CEST) Received: from isjsys.int.i1.dk (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id ADCD026F02 for ; Tue, 16 Jul 2013 17:17:38 +0200 (CEST) From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= To: dime@ietf.org Date: Tue, 16 Jul 2013 17:17:38 +0200 Message-ID: <7281625.rlZnqXJlo6@isjsys.int.i1.dk> User-Agent: KMail/4.10.3 (Linux/3.7.10-1.16-desktop; KDE/4.10.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Dime] New Overload Solution Approach 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, 16 Jul 2013 15:17:44 -0000 On Tuesday 16 July 2013 09:58:53 Hannes Tschofenig wrote: > I submitted a new approach for dealing with overload signaling in Diameter. ... > 1) Document with architectural principles and the information model > http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt >5.2.2 Period-Of-Validity AVP ... > The maximum value in this AVP is 5 > minutes, which is also the default value. If this AVP is absent in a > subsequent message then the indicated value is valid till the next > overload report is received. That seems unclear to me. So if the host doesn't send an overload report for 6 minutes it can effectively achieve a value larger than 5 minutes? The limit of 5 minutes seems a bit arbitrary to me. >5.2.3. Overload AVP ... > NO_OVERLOAD 0 The Diameter server uses this value > to indicate that it is currently not overload and that the > Diameter client should not reject any request. I suggest that instead of "reject any request" to use the language used in the other values: NO_OVERLOAD 0 The Diameter server uses this value to indicate that it is currently not overloaded and that the Diameter client may send further requests. >5.3.2. Load AVP > The Load AVP (AVP code TBD) is of type Unsigned32. The indicated > value MUST be between 0 and 10. The range 0..10 seems a bit arbitrary to me. Why not 0..99? Or 0..2^32-1 The values cannot be compared between servers anyway, the range may not be linear, it may be asympmatic, so why not let servers report as they see fit and only require that 0 means no load, and 2^32-1 means extreme load, and that values between those two extremes means a load between those to extremes (non-descending). /isj From jouni.nospam@gmail.com Tue Jul 16 14:00:37 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 D837621F93D4 for ; Tue, 16 Jul 2013 14:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9po6lZXM7JJ6 for ; Tue, 16 Jul 2013 14:00:21 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id E799521F9F13 for ; Tue, 16 Jul 2013 14:00:20 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c41so632869eek.40 for ; Tue, 16 Jul 2013 14:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PD+lEQFz2XS+jpzl/EF1pHB2iGuvCfS+miJwa9noUDM=; b=QJXcMHFxLO8Ma88tyymrQTi5vV6V/wmR7Un5jPGEjZaF8XWzQ13WUdGKiljFv24IJ9 t41Aa4sLyhDjBeT8xbawh810z+QT+osmhYgOdbhMWJwJIQVL3lJL/q2jjJG2sHPzcl6k vGH8q0j+q1CdzXSZlH6hlMzQfxCt2AGkQzIaUhcV5rtH/2a0TmewIwLhcgRRY6MUSwJT zz5o5ajLuBPcYozw9XfSkq1IjMfNGzDoAMen0FP5GIX0LvGBgspXWbzB7Cy4ykGB5lJt V9TXolfxyEFqJCTkfk5bgZh6EQCfvW3tPXKRgPEqQnSp8ZwMCB3YO7VwHFz3Mim6IVdi xDvg== X-Received: by 10.15.24.9 with SMTP id i9mr2781344eeu.28.1374008418078; Tue, 16 Jul 2013 14:00:18 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id n42sm5543994eeh.15.2013.07.16.14.00.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 14:00:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 17 Jul 2013 00:00:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 16 Jul 2013 21:00:37 -0000 Hannes, I got a quick question to understand these documents a bit better. What is the essential difference to e.g. draft-korhonen-dime-ovl apart from being a stripped down version of it more or less? - Jouni On Jul 16, 2013, at 10:58 AM, Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi all,=20 >=20 > I submitted a new approach for dealing with overload signaling in = Diameter.=20 >=20 > There are three documents:=20 >=20 > - ---------- >=20 > 1) Document with architectural principles and the information model > http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt >=20 > 2) The Diameter Load Balancing Application (DLBA) that specifically = provides the ability to exchange information for load balancing > http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt >=20 > 3) An mechanism to piggyback overload information from the Diameter = server to the Diameter client > = http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.tx= t >=20 > - ---------- >=20 > Probably the most important question is the following: What motivated = me to write these documents? The answer is pretty simple: I was unhappy = with the complexity introduced by the Tekelec proposal. I wanted to = create a simple foundation that can then be extended on a need-by-need = basis (as we do with other Diameter applications as well). I was = wondering how to simply it.=20 >=20 > Ciao > Hannes >=20 > PS: There are various reasons for the complexity in the Tekelec = solution proposal. I have captured some of those reasons (but not all) = in draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I = designed this solution approach in a modular fashion. For example, a = deployment may choose not to use the load balancing component (as such = it is optional) in case there is no load balancing between different = servers (for a given Diameter application) or in case load balancing is = accomplished using other techniques. (Needless to say that companies = have used load balancing in Diameter before this work has started.) >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJR5P0+AAoJEGhJURNOOiAtwQwH/AltiRpY0rOx0J4KMRM7ZELn > 13mfj4ctQrn8qTDtlS2xE0V40lGPzfstcbaWQiKhVtiZePB1kFusWYUXyhST6p0A > grXolprsL4vl+wZifGSkwny62/VJbNkjQ7coiiQrutcInUmXV8IUjsXntK7KjHfX > sh6r6pCVLNRwh8SaJzbxogItssb2+StpbDgDvryNFVL9TgYhdg8XMRCN/4RgqP7D > QObBw3/TBORrE3RAYmOo/hF3zPf6qiw8bePh51uW7Ve+hgEzYuuxYdByFFlkSEKq > sZUUXFMnrEs1sr+uzhLOtg5o9e1z9G78V9Ye1G5it+zU+qoBwdSr6m2/Dzpsqj8=3D > =3DdADz > -----END PGP SIGNATURE----- > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Jul 18 02:32: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 8267C11E80FF for ; Thu, 18 Jul 2013 02:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HycWyhl06WKn for ; Thu, 18 Jul 2013 02:32:39 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C529511E80F7 for ; Thu, 18 Jul 2013 02:32:38 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so1116726bkc.10 for ; Thu, 18 Jul 2013 02:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=dnlUc1PbihA/H0qsS631GtNLALf66xciFAPA1HpOknI=; b=HYW+ouHgVzEP4CcyfMK+lpnROKI77iQFqBG8CCg4NV9G2Xq+GuMIF2sfTQXy9w+sh6 7r0draxiwmBtN22EqaBHPpmwYjkO3e7hnJ8O5VTqxIic6EHLJmICDjf44B9dPTxBAxqU P9UBctW0AV5BMGQyvLm9OzqjdyiktooB0cRWXS0OMCJTBCXbUo3LdMuatk1vKcvbsmrW qIWGxrArKzf2gIgXYvuttYoD379JkUiPe5QeLBsZkdhQ5M6EtMVTK+1GvpXyvEb33IIg 5totj38YlX351XjMb8TuNcijZLynKguuBcKYuvrgumM7Zgj9eJnXTh2P7tgO/jmp3aqB qUkw== X-Received: by 10.204.232.196 with SMTP id jv4mr1592449bkb.159.1374139957885; Thu, 18 Jul 2013 02:32:37 -0700 (PDT) Received: from host-109-204-179-26.tp-fne.tampereenpuhelin.net (host-109-204-179-26.tp-fne.tampereenpuhelin.net. [109.204.179.26]) by mx.google.com with ESMTPSA id px7sm2984126bkb.9.2013.07.18.02.32.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 02:32:37 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jul 2013 12:32:38 +0300 Message-Id: <62E0392E-D271-470A-81D1-A78CAFDB69EE@gmail.com> To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "dime-chairs@tools.ietf.org" Subject: [Dime] draft agenda has been uploaded 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, 18 Jul 2013 09:32:39 -0000 Folks, The draft agenda is here: = http://www.ietf.org/proceedings/87/agenda/agenda-87-dime In a case we missed someone or you think your timeslot is too short, = just let the chairs know. - Jouni & Lionel From hannes.tschofenig@gmx.net Thu Jul 18 02:38:31 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 60A7811E8103 for ; Thu, 18 Jul 2013 02:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGK7nzGp9W+F for ; Thu, 18 Jul 2013 02:38:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id AF33111E80D7 for ; Thu, 18 Jul 2013 02:38:26 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MGEv5-1UtMsp1sIB-00F9JI for ; Thu, 18 Jul 2013 11:38:24 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 18 Jul 2013 11:38:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> References: To: Jouni Korhonen X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:A+illi9NKHFaB3XVHcv3BLsO1phveyqNfy/pYu3pe1i3brP48XK OxC62QyRIseLVXwnSAa8wNXuK8AGui2jTndCg8S3x8LNraxcRZ38SJrnzn1Wjqdl+mvAGb0 KRUNqvApU83QjEaV9wIu4cXx3r/AhPiGLI8+fVBAcOmq9GSlBCgBMhGz5Tw3X1xxNM4KFpu m8dGJonz0LEqAxkg/Rg3A== Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 09:38:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Jouni,=20 a very direct question.=20 There are two differences:=20 1) The load balancing and the overload communication is separated into = two independent documents. I believe they are different in their nature. = While this may be seen only as a document handling issue many companies = already have solutions for load balancing in use today. They are quite = likely going to re-use their existing stuff while they may still be = interested in the end-to-end overload signaling. 2) The overload signaling uses a piggybacking approach and it more or = less extends what is in the base specification. While the functionality = in the Diameter base specification is quite simplistic I am not = convinced that a minor add-on is not sufficient to solve the overload = problems we have seen today.=20 As you mentioned, it is also stripped down. While each feature in the = OVL draft has a purpose it is nevertheless an optimization. There is a = tradeoff between adding benefits because of the optimizations (in the = amount of outsourcing of policy decisions from the Diameter server to = the Diameter client / Diameter agents) but there is also a price that is = paid for it in form of implementation cost (and license costs for IPR).=20= Hope that this makes sense.=20 Ciao Hannes On Jul 16, 2013, at 11:00 PM, Jouni Korhonen wrote: > Hannes, >=20 > I got a quick question to understand these documents a bit better. > What is the essential difference to e.g. draft-korhonen-dime-ovl > apart from being a stripped down version of it more or less? >=20 > - Jouni >=20 >=20 >=20 >=20 > On Jul 16, 2013, at 10:58 AM, Hannes Tschofenig = wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Hi all,=20 >>=20 >> I submitted a new approach for dealing with overload signaling in = Diameter.=20 >>=20 >> There are three documents:=20 >>=20 >> - ---------- >>=20 >> 1) Document with architectural principles and the information model >> http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt >>=20 >> 2) The Diameter Load Balancing Application (DLBA) that specifically = provides the ability to exchange information for load balancing >> http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt >>=20 >> 3) An mechanism to piggyback overload information from the Diameter = server to the Diameter client >> = http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.tx= t >>=20 >> - ---------- >>=20 >> Probably the most important question is the following: What motivated = me to write these documents? The answer is pretty simple: I was unhappy = with the complexity introduced by the Tekelec proposal. I wanted to = create a simple foundation that can then be extended on a need-by-need = basis (as we do with other Diameter applications as well). I was = wondering how to simply it.=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: There are various reasons for the complexity in the Tekelec = solution proposal. I have captured some of those reasons (but not all) = in draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I = designed this solution approach in a modular fashion. For example, a = deployment may choose not to use the load balancing component (as such = it is optional) in case there is no load balancing between different = servers (for a given Diameter application) or in case load balancing is = accomplished using other techniques. (Needless to say that companies = have used load balancing in Diameter before this work has started.) >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >>=20 >> iQEcBAEBCgAGBQJR5P0+AAoJEGhJURNOOiAtwQwH/AltiRpY0rOx0J4KMRM7ZELn >> 13mfj4ctQrn8qTDtlS2xE0V40lGPzfstcbaWQiKhVtiZePB1kFusWYUXyhST6p0A >> grXolprsL4vl+wZifGSkwny62/VJbNkjQ7coiiQrutcInUmXV8IUjsXntK7KjHfX >> sh6r6pCVLNRwh8SaJzbxogItssb2+StpbDgDvryNFVL9TgYhdg8XMRCN/4RgqP7D >> QObBw3/TBORrE3RAYmOo/hF3zPf6qiw8bePh51uW7Ve+hgEzYuuxYdByFFlkSEKq >> sZUUXFMnrEs1sr+uzhLOtg5o9e1z9G78V9Ye1G5it+zU+qoBwdSr6m2/Dzpsqj8=3D >> =3DdADz >> -----END PGP SIGNATURE----- >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR57ePAAoJEGhJURNOOiAtcvoH/0axsXl4bYcZYFFsu3W0NLh7 +WXnd8zVV6o90kfbDKt+BltMOuF7DEGFs+m6Z5xPDD7uYm3AjLLgimMCYAUC4s7c mnNiT9swRIoYgYz2/bqh7bQaH6QRWY1pIhlMb9IsJQXcSGHaCa2bkb4BINKLOG8V tPfd40OOmm5cnNp4szyLdln1I8Rend9v9MgRiCF3JB30b/JaIi+QsC/l8KaSDxtc nezkWotOtE1J1S1YeV09ViHTAzJOWqxHikilSMg0BKSh+WxcqZVY4lhNfSU2V2h1 7OzFXJJFYBVPhSvuoAweDtTqlU0dT9ATWxI37wTjouo4XwHPyUsRv1DSAKmXpyc=3D =3D4goN -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Thu Jul 18 02:57:12 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 B7E6E11E8112 for ; Thu, 18 Jul 2013 02:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAxYADe7auhX for ; Thu, 18 Jul 2013 02:57:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4980F21E80BA for ; Thu, 18 Jul 2013 02:57:03 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MOBOi-1V32kR29CO-005XVg for ; Thu, 18 Jul 2013 11:57:00 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <7281625.rlZnqXJlo6@isjsys.int.i1.dk> Date: Thu, 18 Jul 2013 11:56:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <239E545A-BB72-47E0-A38C-0D8B11BAF140@gmx.net> References: <7281625.rlZnqXJlo6@isjsys.int.i1.dk> To: =?iso-8859-1?Q?Ivan_Skytte_J=F8rgensen?= X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:GblJ2PqsC712MK9CD16c/CcQdb7gizTiMj/5hFR2uZLtqM8g2EI QxVVZ/k5OJCp14EEoFPloJXci/87XNA71oLlfQNHLUym0Dwk+NgkVTxKUPJGcEC0rnBf0GK OUadu7+l6lxZi5OwPFDhSE+z7fQD6aecvn7tQnZGOEBC7LX40O/5IZ+0mwjxpE0ewrWDx4A idrLRUbx1SdJAye1JDmag== Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 09:57:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Ivan,=20 thanks for your quick comments.=20 Remarks inline:=20 On Jul 16, 2013, at 5:17 PM, Ivan Skytte J=F8rgensen wrote: > On Tuesday 16 July 2013 09:58:53 Hannes Tschofenig wrote: >> I submitted a new approach for dealing with overload signaling in = Diameter. > ... >> 1) Document with architectural principles and the information model >> http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt >=20 >> 5.2.2 Period-Of-Validity AVP > ... >> The maximum value in this AVP is 5 >> minutes, which is also the default value. If this AVP is absent in a >> subsequent message then the indicated value is valid till the next >> overload report is received. >=20 > That seems unclear to me. So if the host doesn't send an overload = report for 6 minutes it can effectively achieve a value larger than 5 = minutes? > The limit of 5 minutes seems a bit arbitrary to me. When the Diameter server communicates to the Diameter client that is in = an overload situation it also tells the client to reject further = requests that have the same pattern (same domain/same application).=20 But for how long should this policy persist? It certainly has to time = out after some time since otherwise a misconfiguration messes up the = entire system (looking much like a denial of service attack). Hence, = there has to be a maximum limit. The value of 5 minutes is indeed = arbitrary. It is small enough to avoid security problems but enough to = be useful from an overload handling point of view.=20 So, if a Diameter server decides that it does not attach this value = since it wants to go with the default then after 5 minutes the stored = policy is gone. If the Diameter server still experiences an overload = situation then it will have to mark a future message again with the = overload information. The last sentence is supposed to indicate that the lack of the overload = value does not mean that the overload situation has gone away. Instead = is just means that nothing has changed. Maybe I should rephrase the = sentence to make this more clear. =20 >=20 >=20 >> 5.2.3. Overload AVP > ... >> NO_OVERLOAD 0 The Diameter server uses this value >> to indicate that it is currently not overload and that the >> Diameter client should not reject any request. >=20 > I suggest that instead of "reject any request" to use the language = used in the other values: >=20 > NO_OVERLOAD 0 The Diameter server uses this value > to indicate that it is currently not overloaded and that the > Diameter client may send further requests. >=20 >=20 Sounds good to me. Thanks for text suggestion.=20 >=20 >> 5.3.2. Load AVP >> The Load AVP (AVP code TBD) is of type Unsigned32. The indicated >> value MUST be between 0 and 10. >=20 > The range 0..10 seems a bit arbitrary to me. Why not 0..99? The range is indeed arbitrary and it does not really matter what the = range actually is.=20 I personally have no preference. 0-9, 0-99, A-F, high-medium-low, etc.. = The group has decide what they like best.=20 >=20 > Or 0..2^32-1 > The values cannot be compared between servers anyway, the range may = not be linear, it may be asympmatic, so why not let servers report as = they see fit and only require that 0 means no load, and 2^32-1 means = extreme load, and that values between those two extremes means a load = between those to extremes (non-descending). Also fine with me. Regarding the remark that the values cannot be compared between the = servers: For load balancing the only thing that matters is that they are = mapped appropriately into the available range. If a network operator = deploys 2 servers with different hardware configuration then for server = "A" 100 additional requests may produce 10% additional load vs. for the = other only 1%. If they are both report 50% load to the load balancer = then the load balancer does not know about the hardware configuration of = these two machines. So, it will (for example) just send half of the = incoming requests to server A and half of the requests to server B. What = it will then quickly learn is that the load of server "A", the weaker = machine, will increase much faster than with server B. So, it will shift = the load over to server B (assuming such an policy at the load = balancer).=20 Does this make sense?=20 Ciao Hannes >=20 >=20 > /isj >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR57vnAAoJEGhJURNOOiAtLp0H/A5EeN4XJxf8g8+k5uUTJK+z BcxaiYmW3LyRyGJ7LooQnRkkE0g6sqOXWg4yllg/POH9QPLqn+Gf9CbioQsM3qAp S97QRlC6CvNwAdsNwn60xU6gYkunq7Bbod1WL1or/FCfkURgJXZ1EQJWe+RLThdg P2XGej0YjoRJUoVqnGnQiSXbp9DYwkg6QDyAkawu0pdPBnmLK9Cku+50OkvBMOge UlGSw0VXqfodp1KlGdJj6zxy3De1ipbxgz20iK40oLhannv+FfTJODUxd139xDdz sMx0FvLCjNqb+IXkhSuE1dYOLSMqyJWaYSphxcVLbMYDTjSLwZ6GMqEJRRVenYA=3D =3DOMfO -----END PGP SIGNATURE----- From isj-dime@i1.dk Thu Jul 18 03:51:28 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 32CC811E8121 for ; Thu, 18 Jul 2013 03:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR2u8mTHqWTY for ; Thu, 18 Jul 2013 03:51:27 -0700 (PDT) Received: from i1.dk (isjsys5-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:20d:93ff:fe73:ac12]) by ietfa.amsl.com (Postfix) with ESMTP id 6A77E11E8122 for ; Thu, 18 Jul 2013 03:51:25 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 8F5A65C008E; Thu, 18 Jul 2013 12:51:18 +0200 (CEST) Received: from isjsys.int.i1.dk (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTP; Thu, 18 Jul 2013 12:51:18 +0200 (CEST) Received: from isjsys.int.i1.dk (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id 68EEE2681A; Thu, 18 Jul 2013 12:51:18 +0200 (CEST) From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= To: dime@ietf.org Date: Thu, 18 Jul 2013 12:51:18 +0200 Message-ID: <2129391.oh07BU8U66@isjsys.int.i1.dk> User-Agent: KMail/4.10.5 (Linux/3.7.10-1.16-desktop; KDE/4.10.5; x86_64; ; ) In-Reply-To: <239E545A-BB72-47E0-A38C-0D8B11BAF140@gmx.net> References: <7281625.rlZnqXJlo6@isjsys.int.i1.dk> <239E545A-BB72-47E0-A38C-0D8B11BAF140@gmx.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 10:51:28 -0000 On Thursday 18 July 2013 11:56:54 Hannes Tschofenig wrote: > On Jul 16, 2013, at 5:17 PM, Ivan Skytte J=F8rgensen wrote: >=20 > > On Tuesday 16 July 2013 09:58:53 Hannes Tschofenig wrote: > >> I submitted a new approach for dealing with overload signaling in = Diameter. > > ... > >> 1) Document with architectural principles and the information mode= l > >> http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.tx= t > > > >> 5.2.2 Period-Of-Validity AVP > > ... > >> The maximum value in this AVP is 5 > >> minutes, which is also the default value. If this AVP is absent i= n a > >> subsequent message then the indicated value is valid till the next= > >> overload report is received. > > > > That seems unclear to me. So if the host doesn't send an overload r= eport for 6 minutes it can effectively achieve a value larger than 5 mi= nutes? > > The limit of 5 minutes seems a bit arbitrary to me. >=20 > When the Diameter server communicates to the Diameter client that is = in an overload situation it also tells the client to reject further req= uests that have the same pattern (same domain/same application). >=20 > But for how long should this policy persist? It certainly has to time= out after some time since otherwise a misconfiguration messes up the e= ntire system (looking much like a denial of service attack). Hence, the= re has to be a maximum limit. The value of 5 minutes is indeed arbitrar= y. It is small enough to avoid security problems but enough to be usefu= l from an overload handling point of view. >=20 > So, if a Diameter server decides that it does not attach this value s= ince it wants to go with the default then after 5 minutes the stored po= licy is gone. If the Diameter server still experiences an overload situ= ation then it will have to mark a future message again with the overloa= d information. >=20 > The last sentence is supposed to indicate that the lack of the overlo= ad value does not mean that the overload situation has gone away. Inste= ad is just means that nothing has changed. Maybe I should rephrase the = sentence to make this more clear. How about: The maximum value in this AVP is 5 minutes, which is also the default value. If this AVP is absent in= a subsequent message then the indicated value is valid till the next overload report is received or 5 minutes, whichever comes first. > >> 5.3.2. Load AVP > >> The Load AVP (AVP code TBD) is of type Unsigned32. The indicated= > >> value MUST be between 0 and 10. > > > > The range 0..10 seems a bit arbitrary to me. Why not 0..99? >=20 > The range is indeed arbitrary and it does not really matter what the = range actually is. > I personally have no preference. 0-9, 0-99, A-F, high-medium-low, etc= .. The group has decide what they like best. >=20 > > > > Or 0..2^32-1 > > The values cannot be compared between servers anyway, the range may= not be linear, it may be asympmatic, so why not let servers report as = they see fit and only require that 0 means no load, and 2^32-1 means ex= treme load, and that values between those two extremes means a load bet= ween those to extremes (non-descending). >=20 > Also fine with me. >=20 > Regarding the remark that the values cannot be compared between the s= ervers: For load balancing the only thing that matters is that they are= mapped appropriately into the available range. If a network operator d= eploys 2 servers with different hardware configuration then for server = "A" 100 additional requests may produce 10% additional load vs. for the= other only 1%. If they are both report 50% load to the load balancer t= hen the load balancer does not know about the hardware configuration of= these two machines. So, it will (for example) just send half of the in= coming requests to server A and half of the requests to server B. What = it will then quickly learn is that the load of server "A", the weaker = machine, will increase much faster than with server B. So, it will shif= t the load over to server B (assuming such an policy at the load balanc= er). >=20 > Does this make sense? Yes. My main concern about a small value range is that if a load-balancer us= es only that then it may result it non-neglible "route flapping". Yes, = this is a matter of quality-of-implementation, but let's not give them = any excuses. My other concern was when I considered how to implement such a mapping = for the system I work on. It can detect when there is no load, when it = is overloaded, and when it is somewhere inbetween. The problem is "some= where inbetween" where I can only guess (due to large variations in the= deployments). That made me question the range 0..10. I can live the range with 0..10, but I'd prefer the full 2^32 range. /isj From emcmurry@computer.org Thu Jul 18 04:40:56 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 790EC11E812A for ; Thu, 18 Jul 2013 04:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOcPCyBtXGdI for ; Thu, 18 Jul 2013 04:40:51 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8C92711E812C for ; Thu, 18 Jul 2013 04:40:51 -0700 (PDT) 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 1UzmZl-000IYM-Hb; Thu, 18 Jul 2013 11:40:49 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 26746AF7A8B; Thu, 18 Jul 2013 06:40:48 -0500 (CDT) 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: U2FsdGVkX1/HBnVjyc4QbI2L10abhThmIaysijCtXG8= 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 wuFqOWcTJ3DV; Thu, 18 Jul 2013 06:40:48 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 0A6ACAF7A7E; Thu, 18 Jul 2013 06:40:47 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> Date: Thu, 18 Jul 2013 06:40:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 11:40:56 -0000 Hi Hannes, comments inline. Thanks, Eric On Jul 18, 2013, at 4:38 , Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi Jouni,=20 >=20 > a very direct question.=20 >=20 > There are two differences:=20 >=20 > 1) The load balancing and the overload communication is separated into = two independent documents. I believe they are different in their nature. = While this may be seen only as a document handling issue many companies = already have solutions for load balancing in use today. They are quite = likely going to re-use their existing stuff while they may still be = interested in the end-to-end overload signaling. I see your point here, however, balancing is not orthogonal to overload = control. Also, more importantly, load information is useful for = proactive overload control. How can you do proactive overload control = without that sort of information? Or are you saying that proactive = control should be proprietary? >=20 > 2) The overload signaling uses a piggybacking approach and it more or = less extends what is in the base specification. While the functionality = in the Diameter base specification is quite simplistic I am not = convinced that a minor add-on is not sufficient to solve the overload = problems we have seen today.=20 >=20 > As you mentioned, it is also stripped down. While each feature in the = OVL draft has a purpose it is nevertheless an optimization. There is a = tradeoff between adding benefits because of the optimizations (in the = amount of outsourcing of policy decisions from the Diameter server to = the Diameter client / Diameter agents) but there is also a price that is = paid for it in form of implementation cost (and license costs for IPR).=20= >=20 Of course, engineering is always a balance trying to reduce cost (or = other factors) while still meeting requirements. Have you done a pass = through this to see how it maps to requirements? > Hope that this makes sense.=20 >=20 > Ciao > Hannes >=20 > On Jul 16, 2013, at 11:00 PM, Jouni Korhonen wrote: >=20 >> Hannes, >>=20 >> I got a quick question to understand these documents a bit better. >> What is the essential difference to e.g. draft-korhonen-dime-ovl >> apart from being a stripped down version of it more or less? >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >> On Jul 16, 2013, at 10:58 AM, Hannes Tschofenig = wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>> Hi all,=20 >>>=20 >>> I submitted a new approach for dealing with overload signaling in = Diameter.=20 >>>=20 >>> There are three documents:=20 >>>=20 >>> - ---------- >>>=20 >>> 1) Document with architectural principles and the information model >>> http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt >>>=20 >>> 2) The Diameter Load Balancing Application (DLBA) that specifically = provides the ability to exchange information for load balancing >>> http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt >>>=20 >>> 3) An mechanism to piggyback overload information from the Diameter = server to the Diameter client >>> = http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.tx= t >>>=20 >>> - ---------- >>>=20 >>> Probably the most important question is the following: What = motivated me to write these documents? The answer is pretty simple: I = was unhappy with the complexity introduced by the Tekelec proposal. I = wanted to create a simple foundation that can then be extended on a = need-by-need basis (as we do with other Diameter applications as well). = I was wondering how to simply it.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> PS: There are various reasons for the complexity in the Tekelec = solution proposal. I have captured some of those reasons (but not all) = in draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I = designed this solution approach in a modular fashion. For example, a = deployment may choose not to use the load balancing component (as such = it is optional) in case there is no load balancing between different = servers (for a given Diameter application) or in case load balancing is = accomplished using other techniques. (Needless to say that companies = have used load balancing in Diameter before this work has started.) >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>>=20 >>> iQEcBAEBCgAGBQJR5P0+AAoJEGhJURNOOiAtwQwH/AltiRpY0rOx0J4KMRM7ZELn >>> 13mfj4ctQrn8qTDtlS2xE0V40lGPzfstcbaWQiKhVtiZePB1kFusWYUXyhST6p0A >>> grXolprsL4vl+wZifGSkwny62/VJbNkjQ7coiiQrutcInUmXV8IUjsXntK7KjHfX >>> sh6r6pCVLNRwh8SaJzbxogItssb2+StpbDgDvryNFVL9TgYhdg8XMRCN/4RgqP7D >>> QObBw3/TBORrE3RAYmOo/hF3zPf6qiw8bePh51uW7Ve+hgEzYuuxYdByFFlkSEKq >>> sZUUXFMnrEs1sr+uzhLOtg5o9e1z9G78V9Ye1G5it+zU+qoBwdSr6m2/Dzpsqj8=3D >>> =3DdADz >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJR57ePAAoJEGhJURNOOiAtcvoH/0axsXl4bYcZYFFsu3W0NLh7 > +WXnd8zVV6o90kfbDKt+BltMOuF7DEGFs+m6Z5xPDD7uYm3AjLLgimMCYAUC4s7c > mnNiT9swRIoYgYz2/bqh7bQaH6QRWY1pIhlMb9IsJQXcSGHaCa2bkb4BINKLOG8V > tPfd40OOmm5cnNp4szyLdln1I8Rend9v9MgRiCF3JB30b/JaIi+QsC/l8KaSDxtc > nezkWotOtE1J1S1YeV09ViHTAzJOWqxHikilSMg0BKSh+WxcqZVY4lhNfSU2V2h1 > 7OzFXJJFYBVPhSvuoAweDtTqlU0dT9ATWxI37wTjouo4XwHPyUsRv1DSAKmXpyc=3D > =3D4goN > -----END PGP SIGNATURE----- > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Jul 18 05:04: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 0B30921F9A1C for ; Thu, 18 Jul 2013 05:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emuxnnRCeSm7 for ; Thu, 18 Jul 2013 05:04:01 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 315AC21E80C5 for ; Thu, 18 Jul 2013 05:04:01 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id mz10so1147216bkb.36 for ; Thu, 18 Jul 2013 05:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cyZiqCsokzkB6TzeN4eBG3awRAbny+iUoItx17N4M5o=; b=KMZ06eKwfNvjc22rn2NbfklZ6x9mWywNvKH1IN9Oq5k68hgk31P6/9oKXAKY7tZOLf FEJBuqfWhldoC5iDMhsOfOZviPgRabRcMiJt/WcWkxdYrw+p3KTBOtzAUXJGNu9JpA1H dRi/HB3An/RJfOONvF4k+jwTpvDZvgpDUlFK36qYb7u7XjoetjGQa9WdfcPOj4G/V4Cm nO9GvQiaXngS9zNjy9igoTM71sF7lSmmptynFIRAesZdKHDK5/5bIvQqc64gKqyKHkcy gozXW1LSHiRF8MXewkRVZGknEHkjkhBNa+0syLA++I3tp2WYRJe8V4mFhnV9OGz6a2QS bo2w== X-Received: by 10.205.9.129 with SMTP id ow1mr1698833bkb.43.1374149029271; Thu, 18 Jul 2013 05:03:49 -0700 (PDT) Received: from host-109-204-179-26.tp-fne.tampereenpuhelin.net (host-109-204-179-26.tp-fne.tampereenpuhelin.net. [109.204.179.26]) by mx.google.com with ESMTPSA id ps10sm3262621bkb.14.2013.07.18.05.03.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 05:03:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> Date: Thu, 18 Jul 2013 15:03:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 12:04:02 -0000 > Of course, engineering is always a balance trying to reduce cost (or = other factors) while still meeting requirements. Have you done a pass = through this to see how it maps to requirements? >=20 A meta question. Does the xyz solution draft need to meet all = requirement i.e. if a=20 solution is just a subset could it skip e.g. some MUSTs if they plain = are not part of the solution proposal? - Jouni From emcmurry@computer.org Thu Jul 18 05:28: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 2FA0C21E80DA for ; Thu, 18 Jul 2013 05:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSmYqKtfN7ue for ; Thu, 18 Jul 2013 05:28:51 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 538A421E80CA for ; Thu, 18 Jul 2013 05:28:51 -0700 (PDT) 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 1UznKE-000Lib-2h; Thu, 18 Jul 2013 12:28:50 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id E0145AF9AF2; Thu, 18 Jul 2013 07:28:47 -0500 (CDT) 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: U2FsdGVkX18U3rQ+ZrWq2FDi2zQ9gU6RqIJKtRm/wY8= 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 xYg_AlOp8DCB; Thu, 18 Jul 2013 07:28:47 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id BDEA7AF9AE9; Thu, 18 Jul 2013 07:28:47 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> Date: Thu, 18 Jul 2013 07:28:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 12:28:57 -0000 On Jul 18, 2013, at 7:03 , Jouni Korhonen = wrote: >=20 >=20 > >=20 >=20 >> Of course, engineering is always a balance trying to reduce cost (or = other factors) while still meeting requirements. Have you done a pass = through this to see how it maps to requirements? >>=20 >=20 > A meta question. Does the xyz solution draft need to meet all = requirement i.e. if a=20 > solution is just a subset could it skip e.g. some MUSTs if they plain = are not part > of the solution proposal? >=20 Well, wasn't the point of the requirements to figure out and define what = solutions need to do? (Notice I put an 's' on there. It's possible to = use more than one, although that may cause other issues). The net is = that the general consensus of all the various experts and stakeholders = that contributed to and reviewed the requirements was that the MUST = levels were needed for resulting solutions. So, I think the short answer to your question is no, we should not throw = out proposals that don't meet all of the requirements. However, we = should evaluate them against the requirements and understand where they = are deficient and how the remaining requirements would be met (or why = the requirements were incorrect, in which case I think this would need = to be pretty well supported, given the time we have spent on those. For = example, see Ben's analysis draft of one of the SHOULD level = requirements). Thanks, Eric From Hannes.Tschofenig@gmx.net Thu Jul 18 05:32:41 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 97BF121E80DA for ; Thu, 18 Jul 2013 05:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IftF+7XGa1kv for ; Thu, 18 Jul 2013 05:32:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 382AA21E80EA for ; Thu, 18 Jul 2013 05:32:36 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LbMF8-1UJHtt142c-00kxMR; Thu, 18 Jul 2013 14:32:31 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> Date: Thu, 18 Jul 2013 14:32:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF8FAA4-651D-49D9-8616-D0F6D03F7AFE@gmx.net> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> To: Jouni Korhonen X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:YloeX6XDIJ5G2dajT1idfiOBcOAZJgYYeVmLFvN+EBHknmhIORG wyICVWWEcqn8mmGkz515pr+cHTszyRubhMqlDV+HtDdTBN+X84e7kzWeWfRKHtV6d8C7phZ 5+usIWNYK5h3zpurWvPpuL0+GEr1qh+a7MXwQZGP2YqHnyVlNRN7WoA+kCqfFuiE5HSQEIE x30+579vMPJnsSaJSu03A== Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 12:32:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 That's a good question, Jouni.=20 There has to be some minimum level of functionality needed for = interoperability and then there might be extra functionality that is = optional to implement.=20 You are asking me actually two types of questions:=20 1) Do both (minimum & extra functionality) need to be described in the = same document?=20 2) What is the minimum level of functionality? My response to (1) is that they should be described in different = documents (as we are likely going to see different features being = proposed over time anyway as people gain more experience with the = technology).=20 I made a minimalistic proposal for (2). I guess it will be hard to have = even less functionality since you are then quickly with the = functionality provided in the Diameter base specification = (DIAMETER_TOO_BUSY).=20 Maybe this is actually a decision that the chairs have to make about how = the document management is done.=20 I would hope that vendors who have to implement this stuff have some = ideas about what the minimum should be. =46rom the mailing list = discussion so far I do not have clear view what the different companies = are willing to implement. Maybe folks are not that far yet in their = company-internal investigations. It is also sometimes hard to say with = companies participating in the 3GPP since the standardization people are = different from the product people and what is being standardized now may = (if things work out great) get implemented in 3-5 years by a completely = different set of people. It might also be worthwhile to point out that more optimizations = typically translates to more patents. We have already to deal with the = Tekelec patents and who knows what other things are lurking around the = corner... Ciao Hannes On Jul 18, 2013, at 2:03 PM, Jouni Korhonen wrote: >=20 >=20 > >=20 >=20 >> Of course, engineering is always a balance trying to reduce cost (or = other factors) while still meeting requirements. Have you done a pass = through this to see how it maps to requirements? >>=20 >=20 > A meta question. Does the xyz solution draft need to meet all = requirement i.e. if a=20 > solution is just a subset could it skip e.g. some MUSTs if they plain = are not part > of the solution proposal? >=20 > - Jouni >=20 >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5+BeAAoJEGhJURNOOiAt3+kH/3KXQxW8ms2VOsoytPx6iOjI hYhHON9e9ugv3sZ8ac4BP+BnOPhWIq3rTfvMqJsPP/rpwhLij/5moiBUp9QxMy7p 8lvbtzz2N9lu3qCLbKuXtMwo18cVmTFmGuOVPx6RFWqzc85OuhGZHvQ/pnVX9qWq V1jT30K5pzwtdtyn3Eh/JYFChLcG8VpFKYcYhajFzy7ot+OPFhIOkmXg7MjyQz/n lzPyrZx9Hde/zv/KAKSEDiYLRaXzMtmowhHOp1pt1tz0ZvQFQNUobHd8bVLqXBjJ b7o0P2fSYTaefGfmjr0WAn5JFKbP34TMB4qTaUrMu/DVnPgvweTaaiKxIGNVDGg=3D =3DDct0 -----END PGP SIGNATURE----- From jouni.nospam@gmail.com Thu Jul 18 05:39: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 352B321E80EA for ; Thu, 18 Jul 2013 05:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERoBxI00IneI for ; Thu, 18 Jul 2013 05:39:28 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4626C21E80E5 for ; Thu, 18 Jul 2013 05:39:28 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eh20so163117lab.1 for ; Thu, 18 Jul 2013 05:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vPIZCUaPCoRsQg0nBQ53AY7cGTzPp71Hvp7ogbXL1yg=; b=Fl6alSw6ohpl67Pk3KyBQcCZvN6hOGo8lnT+IO4DL2+H6Hslhb5XpWpfTpHOmVPnEl QRqFBjTuIB53SbNNSF/wSwhx+s3FZdH+vzq5gNDLOMGOiM/jiYgNZ4piy5N0Uq6Gpth0 4Vvp8y7QpbN8emMcdSCEK9LHaGplSNlpqEbGF4huvqsmLygjW0i0DKmH5MZUFhF9PZd+ NisdB6Z46XRD7et9EwHWfz6g1D/u4tkcyIiXcVDHr8hL3sUqwdY0pngf1kJlPnam/PIA HzqLnLyGL3DNzF32pg2e3s5ngcg0uqRyJv6vqPJbgykh1kTuxv24anx1FtoTGXFEOrQh 0HyQ== X-Received: by 10.152.116.19 with SMTP id js19mr5129245lab.72.1374151163382; Thu, 18 Jul 2013 05:39:23 -0700 (PDT) Received: from [192.168.43.158] (84-231-254-234.elisa-mobile.fi. [84.231.254.234]) by mx.google.com with ESMTPSA id p17sm4396739lbv.11.2013.07.18.05.39.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 05:39:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 18 Jul 2013 15:39:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> To: Ben Campbell X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 18 Jul 2013 12:39:29 -0000 On Jul 14, 2013, at 9:01 PM, Ben Campbell wrote: > On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >=20 >> Hi Martin, >>=20 >> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>=20 >> Perhaps others have thoughts on mixing implicit and explicit scopes? >=20 > I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >=20 > In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" Out of curiosity, would you ever expect NAT between Diameter nodes? Keeping in mind Diameter is a bidirectional protocol by design a NAT does not fit in the base protocol. - Jouni >=20 >=20 >>=20 >> Thanks! >>=20 >> Eric >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 14, 2013, at 7:52 , "DOLLY, MARTIN C" wrote: >>=20 >>> Ben, >>>=20 >>> Is it possible to define a base default =93implicit=94 Scope, where = the Application-ID and the Connection Scopes are mandatory? >>>=20 >>> We see these two being the minimum to be supported independent of = the deployment scenario. >>>=20 >>> Thanks, >>>=20 >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Labs >>> md3135@att.com >>> +1-609-903-3360 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Hannes.Tschofenig@gmx.net Thu Jul 18 05:41:56 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 E244121F9A19 for ; Thu, 18 Jul 2013 05:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDbj09-Accb9 for ; Thu, 18 Jul 2013 05:41:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 978AE21E80E7 for ; Thu, 18 Jul 2013 05:41:51 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MDE6y-1UwUgU1jR6-00GVlO for ; Thu, 18 Jul 2013 14:41:50 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 18 Jul 2013 14:41:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <519A1CC3-2008-4693-B4B5-8404C8710757@gmx.net> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> To: Eric McMurry X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:/uKwe8eylJJ2Shn4FqbKXxe/9C76isZoucrvY+t17rJUufhfGgZ JMtZG1NVV0paxDszsBramOJWz5gjMdLMPXwKefJxTQWo+ZCLhHwqRV3t/QIL0Ur27hzvRlV eqZW5gsiYkuucygzQcm9QiZTEetal7lCjcg7saB3MysXiVth/dl75oldblKn7TnugZiR87w /s+t102HDoEVO5lL+pskg== Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 12:41:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Eric,=20 On Jul 18, 2013, at 2:28 PM, Eric McMurry wrote: > Well, wasn't the point of the requirements to figure out and define = what solutions need to do? The problem with the requirements draft is that it does not give an = answer to a number of questions, in particular as far as the level of = optimizations goes. As you can see from your own solution proposal there = is a lot of complexity sneaks in when you want to support various scopes = (as you call them). Of course, a requirements document does not describe document handling = issues either since those are largely the decision of the chairs (IMHO).=20= Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5+KMAAoJEGhJURNOOiAtKswIAIfgT94CFqy5eg2iZ0OBZxyQ aV/fhYBExUohj7tO1XmSKjIO+Oz+HpVTF//a7fSzPThMzh/MDN5WDclgNzbYFv9e BGdmKoZA/wiIZhMjzpWOAuIvzrXNR/K1WmvE8mBu3r3vjfNk1oWlv9b16/mFtjuB 0kYxpjDG3+rzlI6sMRh0GKt8RACVXAG+X06DsyIldrFazCCyq0MyKme4QLrLmSKr erSJc8RcqOV42bcoHgRbDjPofE2NWeuxAC1mhksMFMw3JT2m8Dhs9xIW9mS5adu+ pV3p1bntFX3Sdp1AQ9p5wt0Wz0Wpe9MWPi/WORg/U2POLl89qNBjJa9lasU5ruo=3D =3DmQBY -----END PGP SIGNATURE----- From jouni.nospam@gmail.com Thu Jul 18 05:51:03 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 366CA21E80E6 for ; Thu, 18 Jul 2013 05:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2vMqT6sQftI for ; Thu, 18 Jul 2013 05:51:02 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9252F21E80E5 for ; Thu, 18 Jul 2013 05:49:43 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id v1so2505345lbd.18 for ; Thu, 18 Jul 2013 05:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AGI5x/F4N2ireuEafnYLFoKdJILTFIUZFo1NPwFD4/Y=; b=v/5BaGpZjtq8amkiZRzXMyzLBIqIsSYf0yGe8azEGs5ZaLv1hI4uehYzBfGShNhB4W 4uXPTfo3ALTgJ8D3wRkEKIV83sucDDrqg3mai2V+JWLb0nDX+0yWJEwtIO98kcboCFEY Dfnq5M0WZDM5TywET2QKXfkmca2iYGiyFE2kZhd/+YGQjX/oODvtvwzLmY9InL2T6dup 7ahHSsP7+a2D7/DAj99gXOHnH2R7VE7PDoJhCaVFBnMjrnN53Ht8hdmLgOHA0z5m5NSf +uQjPCIABJyBb6+VBX9SQMU4ZsA6OFRjCK5aof+sML65R3+YO8qfuTDuMRPQsVs7Cl0a g9UQ== X-Received: by 10.112.146.33 with SMTP id sz1mr5498780lbb.47.1374151782541; Thu, 18 Jul 2013 05:49:42 -0700 (PDT) Received: from [192.168.43.158] (84-231-254-234.elisa-mobile.fi. [84.231.254.234]) by mx.google.com with ESMTPSA id n17sm4430797lbv.2.2013.07.18.05.49.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 05:49:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> Date: Thu, 18 Jul 2013 15:48:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7C03DB36-EBF3-45FB-AEB0-A029C55C2DB2@gmail.com> References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 18 Jul 2013 12:51:03 -0000 On Jul 14, 2013, at 8:49 PM, Ben Campbell wrote: > On Jul 14, 2013, at 7:49 AM, "DOLLY, MARTIN C" wrote: >=20 >> Ben, >>=20 >> Is there a need for both Connection and Host Scopes? If so why? >=20 > I'm on the fence on this one. I think we definitely need Connection. I = have mixed feelings about Host. >=20 > Many large capacity Diameter implementations are built as clusters of = boxes, or blades on a shelf. In my experience, these clusters often = present themselves as a single Diameter node. This creates situations = where two peers may have many transport connections between them. Erm.. lets be exact with the terminology here. In the above do you mean by "two peers may have many transport connections between them" that = these many connections are between exactly two DiameterIdentities? Anyway, IMHO I assumed that the connection scope could be identified by IP addresses and the host scope by DiameterIdentities.=20 - Jouni > On the surface, this seems to argue for "Host", since you could = theoretically send a single report on one connection, and have it affect = all connections to that host. It might also have an advantage in = preventing a node from opening new connections to an already overloaded = peer. >=20 > On the other hand, it's not always easy to know that two different = transport connections actually terminate on the same host. So even if = one were to send a report at the Host scope, one is likely to still need = to send it on all open transport connections. If so, then the advantage = of Host may go away. The Host scope could also imply a need for all of = the blades in a "node" to synchronize their views of peer overload = state. I suspect this may be difficult for some implementations. >=20 > So I lean towards thinking we need Connection, but that Host may be = redundant. But I would like to hear any arguments to the contrary. >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Jul 18 06:00:24 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 850A521E80E6 for ; Thu, 18 Jul 2013 06:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTmEf6l5KGlO for ; Thu, 18 Jul 2013 06:00:24 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5A92D21E80EC for ; Thu, 18 Jul 2013 06:00:17 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ev20so753560lab.18 for ; Thu, 18 Jul 2013 06:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WJ+Iy+M930lPa7fgdI1ufb9Z9AZvVQTRT37Ry7MJap8=; b=XQ2Mz+mN3eHtDTGqWKBp+crCiGBXVb8QuPccbd2iVHhqhr/sScJKVA/Tzj5pA9J1Za TQOQI3V8kqC2yws58wCyc8XIqKquVV7GVISLPmqScMdlZGALrb5qyWEQMuJm1yfSvLyo 3cmHQksmRdqhk8BbtJATaGvB9qoeWCkcsArACRb0vwrLgpeiqwmFVKObLgS8PT8QxA4y n9BObEcFMy7YLVlecFsrpOmlw9ShtESWmuo+YAiIkxodb1dBIu97/FlTh6IRQ9hA/vKe UdKxy5/CIXDyLGTdJ44QbcB93kDKRnDRN6aOwSS6eBXJgsuZwezo0XkX6HYr+qvApJna 3dlw== X-Received: by 10.112.201.232 with SMTP id kd8mr5269159lbc.32.1374152414990; Thu, 18 Jul 2013 06:00:14 -0700 (PDT) Received: from [192.168.43.158] (84-231-254-234.elisa-mobile.fi. [84.231.254.234]) by mx.google.com with ESMTPSA id g7sm4138587lae.6.2013.07.18.06.00.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 06:00:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 18 Jul 2013 16:00:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F1C9DDF-BD73-4F65-A3B2-7199B36B3F9B@gmail.com> References: To: Eric McMurry X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages 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, 18 Jul 2013 13:00:24 -0000 A meta question regarding the use of the DWR/DWA. Are we then OK = universally assuming & requiring RFC6733 as the minimum base protocol version for overload = control solution? The requirement draft assumes RFC6733 but how about external SDOs with their = specifications when it comes to overload solution? - Jouni On Jul 14, 2013, at 5:40 PM, Eric McMurry wrote: > Hi Martin, >=20 > The main use of DWR/DWA for this would be quiescent connections. Take = a case where an overload condition has caused a server to request a = complete traffic backoff. Once that happens, until the timer on that = overload control information pops, the clients won't send any traffic = for scope encompassed by that backoff request. If that server recovers = before that backoff period, the client will still not send it any = traffic. Using a DWR though, the server can send new control = information at any time, so that it could indicate to the client when it = has recovered, so that traffic can begin flowing. The real use of this = is to ensure that links don't stay quiescent any longer than necessary. = The general difference though between using the watchdog messages vs. = other applications is that they can be sent in an ad hoc fashion without = side effects. >=20 > Thanks, >=20 > Eric >=20 >=20 > On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: >=20 >> Ben, >> =20 >> Everyone agrees that load/overload information needs to be conveyed = in Application level messages. >> =20 >> Under what circumstances is there a benefit conveying the = load/overload information in diameter Connection level messages (e.g., = DRA, DRW)? >> =20 >> Thanks, >> =20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Labs >> md3135@att.com >> +1-609-903-3360 >> =20 >> =20 >> =20 >> _______________________________________________ >> 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 emcmurry@computer.org Thu Jul 18 06:05:58 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 230D011E813D for ; Thu, 18 Jul 2013 06:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMJ0b8lUiO1p for ; Thu, 18 Jul 2013 06:05:47 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5D111E8133 for ; Thu, 18 Jul 2013 06:05:47 -0700 (PDT) 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 1Uznty-000I8D-05; Thu, 18 Jul 2013 13:05:46 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 377ECAFB4F7; Thu, 18 Jul 2013 08:05:44 -0500 (CDT) 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: U2FsdGVkX1/iJWbscwVTlXpCiAsfYEwQKMbMGp4hfzg= 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 s_YVNwVC6Ucf; Thu, 18 Jul 2013 08:05:44 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 2ED13AFB4F1; Thu, 18 Jul 2013 08:05:44 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <519A1CC3-2008-4693-B4B5-8404C8710757@gmx.net> Date: Thu, 18 Jul 2013 08:05:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6C15E447-6B87-4889-893B-29011ACC145C@computer.org> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> <519A1CC3-2008-4693-B4B5-8404C8710757@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 13:05:58 -0000 Hi Hannes, On Jul 18, 2013, at 7:41 , Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi Eric,=20 >=20 > On Jul 18, 2013, at 2:28 PM, Eric McMurry wrote: >=20 >> Well, wasn't the point of the requirements to figure out and define = what solutions need to do? >=20 > The problem with the requirements draft is that it does not give an = answer to a number of questions, in particular as far as the level of = optimizations goes. As you can see from your own solution proposal there = is a lot of complexity sneaks in when you want to support various scopes = (as you call them). >=20 I agree that optimization is not in there, nor should it have been. = Those are considerations for the solution, and for the implementations. = Any time optimization is done though, it is within constraints. In this = case there have been constraints generally agreed to. > Of course, a requirements document does not describe document handling = issues either since those are largely the decision of the chairs (IMHO).=20= I'm pretty sure those requirements didn't describe any document handling = issues. Any statements I made were, of course, my own opinions. As are = any made here when not wearing a hat :-). thanks, Eric From emcmurry@computer.org Thu Jul 18 06:26:25 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 96E0211E8143 for ; Thu, 18 Jul 2013 06:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXlR2SqJriC1 for ; Thu, 18 Jul 2013 06:26:18 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8B11E813B for ; Thu, 18 Jul 2013 06:26:16 -0700 (PDT) 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 1UzoDk-0003PX-9q; Thu, 18 Jul 2013 13:26:12 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id ECB38AFC2AF; Thu, 18 Jul 2013 08:26:10 -0500 (CDT) 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: U2FsdGVkX1+fMz7ZCasdFmk41PfNygbA6DGmCkOHZwE= 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 MgTnUK1rwiNN; Thu, 18 Jul 2013 08:26:10 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id CCF09AFC2A6; Thu, 18 Jul 2013 08:26:10 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <4F1C9DDF-BD73-4F65-A3B2-7199B36B3F9B@gmail.com> Date: Thu, 18 Jul 2013 08:26:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <447D09C3-06FA-4157-B93D-6B63B5E34924@computer.org> References: <4F1C9DDF-BD73-4F65-A3B2-7199B36B3F9B@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages 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, 18 Jul 2013 13:26:26 -0000 That's a good point Jouni, and is one that was called out in the draft = as I recall. It's hard to answer though. The main consumer of this is likely to be = 3gpp for R12. Perhaps Lionel can comment on wether there is anything = like an official decision on that there. The main consumers of = equipment supporting this will likely be operators. I would think it is = also relevant wether any of them plan to continue support of 3588 in the = time frame this would become available. At any rate, I don't think any of the cases for it show that things will = break if it is not used, just that it will not work as well. =20 thanks, Eric On Jul 18, 2013, at 8:00 , Jouni Korhonen = wrote: >=20 > A meta question regarding the use of the DWR/DWA. Are we then OK = universally assuming & > requiring RFC6733 as the minimum base protocol version for overload = control solution? The > requirement draft assumes RFC6733 but how about external SDOs with = their specifications > when it comes to overload solution? >=20 > - Jouni >=20 >=20 >=20 > On Jul 14, 2013, at 5:40 PM, Eric McMurry = wrote: >=20 >> Hi Martin, >>=20 >> The main use of DWR/DWA for this would be quiescent connections. = Take a case where an overload condition has caused a server to request a = complete traffic backoff. Once that happens, until the timer on that = overload control information pops, the clients won't send any traffic = for scope encompassed by that backoff request. If that server recovers = before that backoff period, the client will still not send it any = traffic. Using a DWR though, the server can send new control = information at any time, so that it could indicate to the client when it = has recovered, so that traffic can begin flowing. The real use of this = is to ensure that links don't stay quiescent any longer than necessary. = The general difference though between using the watchdog messages vs. = other applications is that they can be sent in an ad hoc fashion without = side effects. >>=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >> On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" wrote: >>=20 >>> Ben, >>>=20 >>> Everyone agrees that load/overload information needs to be conveyed = in Application level messages. >>>=20 >>> Under what circumstances is there a benefit conveying the = load/overload information in diameter Connection level messages (e.g., = DRA, DRW)? >>>=20 >>> Thanks, >>>=20 >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Labs >>> md3135@att.com >>> +1-609-903-3360 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 From ben@nostrum.com Thu Jul 18 07:37:14 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 49C0D11E814E for ; Thu, 18 Jul 2013 07:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3EBRKgWDU5Q for ; Thu, 18 Jul 2013 07:37:13 -0700 (PDT) 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 84B3411E80E3 for ; Thu, 18 Jul 2013 07:37:09 -0700 (PDT) Received: from [10.0.1.12] (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 r6IEb2kq092445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 09:37:03 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <7C03DB36-EBF3-45FB-AEB0-A029C55C2DB2@gmail.com> Date: Thu, 18 Jul 2013 09:37:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> <7C03DB36-EBF3-45FB-AEB0-A029C55C2DB2@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 18 Jul 2013 14:37:14 -0000 On Jul 18, 2013, at 7:48 AM, Jouni Korhonen = wrote: >> I'm on the fence on this one. I think we definitely need Connection. = I have mixed feelings about Host. >>=20 >> Many large capacity Diameter implementations are built as clusters of = boxes, or blades on a shelf. In my experience, these clusters often = present themselves as a single Diameter node. This creates situations = where two peers may have many transport connections between them. >=20 > Erm.. lets be exact with the terminology here. In the above do you = mean > by "two peers may have many transport connections between them" that = these > many connections are between exactly two DiameterIdentities? Yes. Whether it was intended by the protocols or not, it does occur in = the field. >=20 > Anyway, IMHO I assumed that the connection scope could be identified = by > IP addresses and the host scope by DiameterIdentities.=20 >=20 The connection scope in draft-roach-dime-overload-ctrl treats the = "Connection" scope to mean "this connection". That is, the connection on = which you receive the report. That indirectly maps to the 5-tuple of the = transport connection, but that's the transport layer's problem to figure = out. > - Jouni From ben@nostrum.com Thu Jul 18 07:37:38 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 7A72211E814C for ; Thu, 18 Jul 2013 07:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VITl1rWiw-Vd for ; Thu, 18 Jul 2013 07:37:38 -0700 (PDT) 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 E993311E8156 for ; Thu, 18 Jul 2013 07:37:36 -0700 (PDT) Received: from [10.0.1.12] (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 r6IEb2kr092445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 09:37:28 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Thu, 18 Jul 2013 09:37:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2A8DBE00-66B1-4216-AB8E-7AFD6720CB15@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 18 Jul 2013 14:37:38 -0000 On Jul 18, 2013, at 7:39 AM, Jouni Korhonen = wrote: >=20 > On Jul 14, 2013, at 9:01 PM, Ben Campbell wrote: >=20 >> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>=20 >>> Hi Martin, >>>=20 >>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>=20 >>> Perhaps others have thoughts on mixing implicit and explicit scopes? >>=20 >> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>=20 >> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >=20 > Out of curiosity, would you ever expect NAT between Diameter nodes? > Keeping in mind Diameter is a bidirectional protocol by design a > NAT does not fit in the base protocol. It has been my experience that we can never assume that some form of NAT = won't exist between any two IP hosts, unless you explicitly forbid it. I = can see some complications for connection setup, but wouldn't be = surprised to see Diameter and/or NAT implementations/deployments figure = a way to make it work. Ben. From maria.cruz.bartolome@ericsson.com Thu Jul 18 12:07: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 C94C221E8178 for ; Thu, 18 Jul 2013 12:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raorBT9OpDFx for ; Thu, 18 Jul 2013 12:07:54 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 495DF11E81D4 for ; Thu, 18 Jul 2013 12:07:53 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-37-51e83d07a99f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 31.B6.19388.70D38E15; Thu, 18 Jul 2013 21:07:51 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.148]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Thu, 18 Jul 2013 21:07:50 +0200 From: Maria Cruz Bartolome To: Ben Campbell , Jouni Korhonen Thread-Topic: [Dime] Diameter Overload - Host vs Connection Scope Thread-Index: AQHOg7V4THMKhiXbuE2j9g2f5vsmTplqX5YAgABpcuA= Date: Thu, 18 Jul 2013 19:07:49 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920A2599@ESESSMB101.ericsson.se> References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> <7C03DB36-EBF3-45FB-AEB0-A029C55C2DB2@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvrS677YtAg8f7jS3md55mt5jbu4LN Yv+6BiYHZo+ds+6yeyxZ8pPJY9bOJywBzFFcNimpOZllqUX6dglcGR1PVjEW3BGpePL1EVsD 4wuBLkYODgkBE4n1z9i6GDmBTDGJC/fWA9lcHEIChxklTh+cxQrhLGGUuHRoLTtIFZuAncSl 0y+YQJpFBLwlDnWzgISZBZQlZu94AFYiLOAgseX9blYQW0TAUeLhvO8sELaVxLq+v2A2i4Cq xM8JB9hBxvACjdnbnwux6hujRO/f9WC9nAL2Eqenz2UEsRmBjvt+ag0TxC5xiVtP5jNBHC0g sWTPeWYIW1Ti5eN/rBC2kkTjkiesEPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJjGKzkIyd haRlFpKWWUhaFjCyrGJkz03MzEkvN9/ECIyag1t+G+xg3HRf7BCjNAeLkjjvZr0zgUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYZ79XiZv6yGzrxCvVtYFCK7nO3pt5wnEzt36B59TSyB3W a1z/R6zdez7XOibie+zMp1375oa0Cem4y2wWXTllja/89duiU7f+38xaM3Np3Y+jz+vcbeZt rk+X0Zodt+UR05GWB1++r+AI9pr/8XtElEjld07drdq3N0wVXdmeWfNgX8Gaomcs9UosxRmJ hlrMRcWJAKaMS0FoAgAA Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 18 Jul 2013 19:07:59 -0000 Hello all, I think there may be some cases where "host" could be useful, e.g. a client= that opens a pool of transport connections (n+k) (then it knows to which h= ost the connections are linked, in fact the pool is managed as a single log= ical connection) to a (multiple node) cluster server. In case there is a c= ommon resource to all the cluster nodes (e.g. a database) that could get ov= erloaded, it could be useful to simply use "host" scope, since it applies t= o the whole cluster (and then to the single logical connection).=20 But it is true that in this case, we could convey overload/load information= to the client to be able to react against this situation using "Connection= ", or even "Application", then I presume we need to look for the minimum se= t of scopes, and here minimum would mean that we cannot convey required inf= ormation without them. Therefore, I think "host" is not into this "minimum= set" of scopes. Best regards /MCruz -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ben= Campbell Sent: jueves, 18 de julio de 2013 16:37 To: Jouni Korhonen Cc: dime@ietf.org Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope On Jul 18, 2013, at 7:48 AM, Jouni Korhonen wrote: >> I'm on the fence on this one. I think we definitely need Connection. I h= ave mixed feelings about Host. >>=20 >> Many large capacity Diameter implementations are built as clusters of bo= xes, or blades on a shelf. In my experience, these clusters often present t= hemselves as a single Diameter node. This creates situations where two peer= s may have many transport connections between them. >=20 > Erm.. lets be exact with the terminology here. In the above do you=20 > mean by "two peers may have many transport connections between them"=20 > that these many connections are between exactly two DiameterIdentities? Yes. Whether it was intended by the protocols or not, it does occur in the = field. >=20 > Anyway, IMHO I assumed that the connection scope could be identified=20 > by IP addresses and the host scope by DiameterIdentities. >=20 The connection scope in draft-roach-dime-overload-ctrl treats the "Connecti= on" scope to mean "this connection". That is, the connection on which you r= eceive the report. That indirectly maps to the 5-tuple of the transport con= nection, but that's the transport layer's problem to figure out. > - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From tom.taylor.stds@gmail.com Thu Jul 18 12:51: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 0865911E81FA for ; Thu, 18 Jul 2013 12:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDwYZ7zRKmKw for ; Thu, 18 Jul 2013 12:51:14 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3C21E8158 for ; Thu, 18 Jul 2013 12:51:11 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so7975677ieb.16 for ; Thu, 18 Jul 2013 12:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EO9aHZq5jcfTs7MoXt13Q/bWaTdjGCoEX8Hz4XGxQ7M=; b=ezI6TyTD0Sz56jKhuvBMRmshEiNJtW1G7V+kZZvMeRvWjbF2nMhOHFhsRHvDZmdT7t KEG7dzzN7K/Phm4rX7qejhuxpsxyyoRralndhtedAlRczqwSXL8YomZoRQEUMOJpNGNx Lc/rAxJBHhlIpNiawmynjWjBesYh8+t/2xPvfw1IckWHsRySG2zOkse03lHyfozJgqel ZFhBjkDsc0NREjeoOxi50xYCbConyU+RPCIEzpBEm2DrKd40ti76Yc91gM/Q9Z3Vh+mN LQAoVuRRdDUcKhwq7OzCk2R3tRmgQhzEeYp2ziCllRmHz3gX7UwfwAwWZ/m88pLUShWj 5hAw== X-Received: by 10.42.113.8 with SMTP id a8mr6813564icq.71.1374177067852; Thu, 18 Jul 2013 12:51:07 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id vc13sm11411707igb.1.2013.07.18.12.51.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 12:51:07 -0700 (PDT) Message-ID: <51E84729.4040407@gmail.com> Date: Thu, 18 Jul 2013 15:51:05 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dime@ietf.org References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> In-Reply-To: <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 19:51:18 -0000 On 18/07/2013 8:03 AM, Jouni Korhonen wrote: > > > > > >> Of course, engineering is always a balance trying to reduce cost (or other factors) while still meeting requirements. Have you done a pass through this to see how it maps to requirements? >> > > A meta question. Does the xyz solution draft need to meet all requirement i.e. if a > solution is just a subset could it skip e.g. some MUSTs if they plain are not part > of the solution proposal? > > - Jouni > [PTT] It seems clear that all agreed requirements must be met eventually. The corollary to that is that any partial solution must not preclude extension to a solution that meets all of the requirements. The two issues I see here are: 1) Is it permissible at design time (i.e., within the WG) to roll out a complete solution in phases? 2) Is it permissible to devise a solution that can be deployed in phases, where the initial phase does not meet all the requirements? Tom From jouni.nospam@gmail.com Thu Jul 18 13:56:03 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 4775C11E8227 for ; Thu, 18 Jul 2013 13:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVhxjdguL28G for ; Thu, 18 Jul 2013 13:56:02 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3BACB21E8124 for ; Thu, 18 Jul 2013 13:54:42 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id 6so1357926bkj.3 for ; Thu, 18 Jul 2013 13:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jOi19hvqG5erPzy52q4gekGhtuQWFSjhcbnvRqqUSqE=; b=ocBZO1pVK9GkcGdoWxBUfqzlfc66fKlascPF+WNlmXNXtQb2g/yp0+8DZ2YEzspkbQ R8LedUuIO6M5ecxUuA9TywlD0Vo5e4VjKSBp/flLSgr0ulRA57Q3sHr85gzNuvS7S/cf TLFI8jrEAmZrdmDKuSU/9i5mUd7WM8ywajWbprOCiM80LoxgMnCmeGJWqwlcjGX2GuyG Fj4wuS4hqsXOxbWOLKVcwG+ZAAlOixgRUXZMt8S+Xq+uFYF5Kx75+tm5541Vzwn3SSPN +6yvHUCun8NExzZrjSXl2tESnSLR0mPeTn8/zO5pP/Hg9Uf8K46yOp6nBut9UcqqkK2s demQ== X-Received: by 10.205.4.197 with SMTP id od5mr1998139bkb.1.1374180881001; Thu, 18 Jul 2013 13:54:41 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:cc42:3d7e:4469:8eea? ([2001:1bc8:101:f101:cc42:3d7e:4469:8eea]) by mx.google.com with ESMTPSA id cy5sm3742787bkb.1.2013.07.18.13.54.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 13:54:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 18 Jul 2013 23:54:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F20406A-CE59-4BEE-9310-E90DDEAB7464@gmail.com> References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> <7C03DB36-EBF3-45FB-AEB0-A029C55C2DB2@gmail.com> To: Ben Campbell X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 18 Jul 2013 20:56:03 -0000 On Jul 18, 2013, at 5:37 PM, Ben Campbell wrote: >=20 > On Jul 18, 2013, at 7:48 AM, Jouni Korhonen = wrote: >=20 >>> I'm on the fence on this one. I think we definitely need Connection. = I have mixed feelings about Host. >>>=20 >>> Many large capacity Diameter implementations are built as clusters = of boxes, or blades on a shelf. In my experience, these clusters often = present themselves as a single Diameter node. This creates situations = where two peers may have many transport connections between them. >>=20 >> Erm.. lets be exact with the terminology here. In the above do you = mean >> by "two peers may have many transport connections between them" that = these >> many connections are between exactly two DiameterIdentities? >=20 > Yes. Whether it was intended by the protocols or not, it does occur in = the field. No problem with that. Just wanted to make sure the above really refers to "multiple instances" transport connections. >> Anyway, IMHO I assumed that the connection scope could be identified = by >> IP addresses and the host scope by DiameterIdentities.=20 >>=20 >=20 > The connection scope in draft-roach-dime-overload-ctrl treats the = "Connection" scope to mean "this connection". That is, the connection on = which you receive the report. That indirectly maps to the 5-tuple of the = transport connection, but that's the transport layer's problem to figure = out. Ack. It would be slightly more easier to make the distinction between = these two scopes if the actual underlying Diameter functionality were = referred. As far as I understood, connection scope allows me to differentiate a = specific transport layer connection when multiple instances is used. Is this = correct? - Jouni >=20 >=20 >> - Jouni >=20 From ben@nostrum.com Thu Jul 18 14:18:13 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 80CDC11E8212 for ; Thu, 18 Jul 2013 14:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEo+tCd33NL9 for ; Thu, 18 Jul 2013 14:18:12 -0700 (PDT) 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 8F64721F9FD1 for ; Thu, 18 Jul 2013 14:18:12 -0700 (PDT) Received: from [10.0.1.12] (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 r6ILHwdJ037777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 16:18:00 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <519A1CC3-2008-4693-B4B5-8404C8710757@gmx.net> Date: Thu, 18 Jul 2013 16:17:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <203A378D-42B8-4101-AAEE-F192AFE77FFD@nostrum.com> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> <519A1CC3-2008-4693-B4B5-8404C8710757@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 21:18:13 -0000 On Jul 18, 2013, at 7:41 AM, Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi Eric,=20 >=20 > On Jul 18, 2013, at 2:28 PM, Eric McMurry wrote: >=20 >> Well, wasn't the point of the requirements to figure out and define = what solutions need to do? >=20 > The problem with the requirements draft is that it does not give an = answer to a number of questions, in particular as far as the level of = optimizations goes. As you can see from your own solution proposal there = is a lot of complexity sneaks in when you want to support various scopes = (as you call them). Hannes, do you disagree with the requirements draft? If so, it would be = helpful to see the details of that sooner than later. The draft has been = through WGLC, and is in AD review. It will likely be up for IETF last = call soon. From ben@nostrum.com Thu Jul 18 14:33:19 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 6A8C011E820B for ; Thu, 18 Jul 2013 14:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LmS06AV6zNY for ; Thu, 18 Jul 2013 14:33:18 -0700 (PDT) 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 262A521F9EC2 for ; Thu, 18 Jul 2013 14:33:17 -0700 (PDT) Received: from [10.0.1.12] (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 r6ILXDXA039468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 16:33:14 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <51E84729.4040407@gmail.com> Date: Thu, 18 Jul 2013 16:33:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <08ED11D7-2CB4-40CF-AEA3-87985A7B6E53@nostrum.com> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> <7AF0407D-F0A0-4578-8841-E76BE42A2614@gmail.com> <51E84729.4040407@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 21:33:19 -0000 On Jul 18, 2013, at 2:51 PM, Tom Taylor = wrote: [...] >>>=20 >>=20 >> A meta question. Does the xyz solution draft need to meet all = requirement i.e. if a >> solution is just a subset could it skip e.g. some MUSTs if they plain = are not part >> of the solution proposal? >>=20 >> - Jouni >>=20 >=20 > [PTT] It seems clear that all agreed requirements must be met = eventually. The corollary to that is that any partial solution must not = preclude extension to a solution that meets all of the requirements. >=20 > The two issues I see here are: >=20 > 1) Is it permissible at design time (i.e., within the WG) to roll out = a complete solution in phases? >=20 I think that's absolutely reasonable. > 2) Is it permissible to devise a solution that can be deployed in = phases, where the initial phase does not meet all the requirements? Also reasonable. But you still need to know what requirements you are = covering or not. And you need a plan for how to extend things to cover = those requirements in the future. For example, it (hypothetically) might make sense to separate load = balancing and overload control, so that you can deploy the load = balancing now, and add the overload control later. But there's a = difference between saying " we will phase in the requirements" than = there is in saying "we will ignore substantial requirements now and hope = we can figure them out (or stop caring) in the future" And even if we take a modular approach to requirements, evaluating how = each component meets requirements would be helpful to select between = competing proposals. Thanks! Ben.= From ben@nostrum.com Thu Jul 18 14:38:58 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 2A9DE21F9C53 for ; Thu, 18 Jul 2013 14:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31nDL5inHXKf for ; Thu, 18 Jul 2013 14:38:57 -0700 (PDT) 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 A927C21E8099 for ; Thu, 18 Jul 2013 14:38:57 -0700 (PDT) Received: from [10.0.1.12] (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 r6ILcpcL040018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 16:38:51 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> Date: Thu, 18 Jul 2013 16:38:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A253875-D289-4B4B-B56F-E7F0F0219740@nostrum.com> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> <8FE57F7F-7BCA-48C2-9593-5CDCA32E7166@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 21:38:58 -0000 On Jul 18, 2013, at 6:40 AM, Eric McMurry wrote: >> 1) The load balancing and the overload communication is separated = into two independent documents. I believe they are different in their = nature. While this may be seen only as a document handling issue many = companies already have solutions for load balancing in use today. They = are quite likely going to re-use their existing stuff while they may = still be interested in the end-to-end overload signaling. >=20 > I see your point here, however, balancing is not orthogonal to = overload control. Also, more importantly, load information is useful = for proactive overload control. How can you do proactive overload = control without that sort of information? Or are you saying that = proactive control should be proprietary? I was going to respond similarly to the draft itself. It may or may not = make sense to separate the how you communicate load and overload = information. But load info is very important to make sure overload = mitigation actions don't just move the problem around, or lead to = cascade failures. From ben@nostrum.com Thu Jul 18 15:13: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 443A811E81D7 for ; Thu, 18 Jul 2013 15:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svoq7LtFw40W for ; Thu, 18 Jul 2013 15:13:17 -0700 (PDT) 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 4B1AA21F9F34 for ; Thu, 18 Jul 2013 15:13:05 -0700 (PDT) Received: from [10.0.1.12] (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 r6IMD24F043978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 17:13:02 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Thu, 18 Jul 2013 17:13:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <837259B1-DF78-4A11-8765-CCA36C0DB8E2@nostrum.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 18 Jul 2013 22:13:18 -0000 Hi Hannes, I've got some comments and questions, organized by draft. draft-tschofenig-dime-overload-arch-00: -- Section 3: I actually with most of the architectural principles, although I suspect = we might quibble over what's really "premature" or "real-world". I'm not sure about the applicability of the "advances in information = technology" paragraph. It seems focus on NFV and orchestration. = Operators are certainly thinking about NFV approaches to handling = dynamic changes in load. But it don't think we're going to see anything = soon that can adapt fast enough to avoid the need to push back against = offers load. However, I think this argues even more for the ability to = rapidly report changes in overload state due to dynamic changes in = capacity. It's also likely to add complexity to the load balancing = problem. I agree that delegation of rejection policy creates complexity. That's = where a lot of the question of scope comes from in some of the earlier = drafts. OTOH, a "request rejection policy language" seems like jumping = off into that complexity with both feet. I also don't see anything = about that in the data elements. -- section 4: Did you intentionally exclude a scenario for where an agent becomes the = "PEP"? -- Section 5:=20 I'm a bit confused by mixing fairly abstract architectural principles = with concrete AVPs. draft-tschofenig-dime-dlba-00: -- Section 1, last paragraph: By "prevent", did you mean "allow"? -- section 4: The use of PPID is interesting. I wonder if that's an alternative for = declaring that a message contains overload information in either of the = piggybacked proposals. =20 draft-tschofenig-dime-overload-piggybacking: -- As others have mentioned, I'd like to see your thoughts on how this = meets the requirements, and what our plan to handle any non-covered = requirements might be if we select this approach. -- section 1:=20 Am I correct to understand this is client-server only? That is, an agent = could not take action to abate overload? -- 3.1: The Supported-Features AVP might be useful for non-adjacent overload = capabilities exchange. I seem to remember that coming up in the past, = but that it was only defined for certain applications? I guess we can = always make it required if you support Overload Control. -- 3.2: In non-trivial topologies, the client can rarely identify "all traffic = bound to server A". How does it know which requests to apply the = rejection policy to? ALso, how does this scale to large numbers of clients? More inline: =20 [...] >=20 > Probably the most important question is the following: What motivated = me to write these documents? The answer is pretty simple: I was unhappy = with the complexity introduced by the Tekelec proposal. I wanted to = create a simple foundation that can then be extended on a need-by-need = basis (as we do with other Diameter applications as well). I was = wondering how to simply it.=20 >=20 [...] Am I correct in that your complain is at least somewhat targeted to the = overload scope concept? Have you had a chance to read my draft on that = subject? I am concerned that, without some ability to express the set of = requests an abatement policy applies to, you're likely to either reduce = all traffic without discrimination, or you are likely to just chase = problems around the network. The operators I have spoken with are extremely worried about an overload = solution that results in oscillation or cascade failures.=20 > PS: There are various reasons for the complexity in the Tekelec = solution proposal. I have captured some of those reasons (but not all) = in draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I = designed this solution approach in a modular fashion. For example, a = deployment may choose not to use the load balancing component (as such = it is optional) in case there is no load balancing between different = servers (for a given Diameter application) or in case load balancing is = accomplished using other techniques. (Needless to say that companies = have used load balancing in Diameter before this work has started.) I'm not necessarily opposed to modularity. But I do expect that we would = evaluate an overload control module proposal against all the relevent = overload control (as opposed to load balancing)requirements, or at least = want to understand the mechanisms for extending it to support more of = the requirements. From jean-jacques.trottin@alcatel-lucent.com Fri Jul 19 06:07:19 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 7B81B11E812F for ; Fri, 19 Jul 2013 06:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWPAg+ENDzkv for ; Fri, 19 Jul 2013 06:07:14 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1037D11E812C for ; Fri, 19 Jul 2013 06:07:14 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6JD7Bj4028422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 19 Jul 2013 08:07:13 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6JD797G027202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 15:07:11 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 19 Jul 2013 15:07:09 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: Ac6AkPt9WmLHlk2/TcKLA1L3YPNX5P///NqAgAA3+YCAADGjAIAAIvkA//2ku2D/9k/6gA== Date: Fri, 19 Jul 2013 13:07:09 +0000 Message-ID: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 19 Jul 2013 13:07:19 -0000 Hi all I come back on my mail I sent you last Tuesday on an implicit scope . As I = said, I am concerned with the number of scopes and their combinations in th= e draft-roach solution which adds complexity, and for this solution I prop= osed to consider an implicit scope which for me should fit many cases.=20 Hannes has a similar concern and in his new solution for overload he focuse= d on a minimal mechanism where there is no more explicit scopes. Behind th= is minimal mechanism, there is an implicit scope which I think is not far f= rom mine. >From these inputs, I think the group should investigate a basic version of = the overload control mechanism which could be also part of the draft roach = solution and see which extensions are needed.=20 Best regards JJacques -----Message d'origine----- De=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 Envoy=E9=A0: mardi 16 juillet 2013 11:12 =C0=A0: dime@ietf.org Cc=A0: BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith (Keith= ) Objet=A0: RE: [Dime] Diameter Overload - Default "Implicit" Scope Hi Ben, Eric and all About the implicit scope, I am thinking to the one used for an overload inf= o which relates to the traffic to which the message transporting this overl= oad info belongs, meaning the traffic between a Destination Host/destinatio= n realm, origin Host/origin realm, for a given Application ID. This scope i= s implicitly defined by these AVPs of the message and does not require a co= mbination of Scope AVPs Another point is on how to limit the number of scopes and their combination= s. Such a number of possibilities increase the complexity of the overload c= ontrol management, which increases the risks. The implicit scope is an answ= er to this question as it can be used instead of the other scopes such as D= estination Host, Origin Host, application ID, connection, and their combina= tions in many cases. Best regards JJacques -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: lundi 15 juillet 2013 01:04 =C0=A0: Eric McMurry Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Diameter Overload - Default "Implicit" Scope On Jul 14, 2013, at 3:59 PM, Eric McMurry wrote: >=20 > On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >=20 >> On Jul 14, 2013, at 9:41 AM, Eric McMurry wrote: >>=20 >>> Hi Martin, >>>=20 >>> Technically that should be possible. I have some concern about mixing = implicit and explicit scopes though. That could be confusing. I would thi= nk it won't be that hard to put those two scopes into control information t= hey apply to.=20 >>>=20 >>> Perhaps others have thoughts on mixing implicit and explicit scopes? >>=20 >> I think this depends on what we mean by implicit scopes. Is an implicit = scope a default that is used if no scope indicators are in an overload repo= rt? Or is it a scope that is assumed to be in all reports even if not indic= ated? I think the first _might_ make sense. The second runs afoul of your c= oncern about mixing implicit and explicit. >>=20 >> In general, though, I lean towards thinking explicit is usually better. = I can see some uses for implicit, for example if an IP address is obscured = by a NAT, a node might not be able to explicitly indicate its IP address to= a peer. But that would be more of an explicit scope indication with an imp= licit value. For example a Host scope with a value of "whatever IP address = you received this request from" >>=20 >=20 > The "whatever IP you received this request from" concept could be useful = for some other scopes also. For example, whatever connection you received = this request on, or whatever application you received this request on. I don't think there's any other way to do "connection" to mean anything but= "this connection". I guess we could explicitly name a 5-tuple, but I suspe= ct that way leads to madness. OTOH, "this application" could just as easily= be named explicitly, so I'm not sure there's a benefit there. > I wonder if that would satisfy the use cases that folks are thinking of = when they bring up implicit scopes? I don't know the answer there--that's why I asked a similar question in the= previous email :-) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Fri Jul 19 06:25:05 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 5740411E8128 for ; Fri, 19 Jul 2013 06:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ybwd5bPBkSn for ; Fri, 19 Jul 2013 06:25:00 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB2111E8117 for ; Fri, 19 Jul 2013 06:25:00 -0700 (PDT) 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 1V0Ag7-000HSi-ID; Fri, 19 Jul 2013 13:24:59 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id DB298B37640; Fri, 19 Jul 2013 08:24:57 -0500 (CDT) 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: U2FsdGVkX1+x/NqhfhGMYE4FKV4OiTPdYwDn8O4afz4= 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 ED-MsODbwCmM; Fri, 19 Jul 2013 08:24:57 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id BC887B37637; Fri, 19 Jul 2013 08:24:57 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Fri, 19 Jul 2013 08:24:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1411A02C-12C9-4D22-821A-650AE4140AE3@computer.org> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 19 Jul 2013 13:25:05 -0000 Hi JJaques, I agree with the general sentiment. We should make things no more = complicated than we need to. The trick is the "than we need to" part. = There are use cases that could be accomplished with a simple mechanism = and fixed scope. There are other use cases that could be done with a = different simple mechanism and a different fixed scope. Really, we = could do that for pretty much any use case, coming up with a set of = mechanisms that work for each particular use case. I would not recommend this approach though, and that's not really what = the requirements are calling for. The potential uses of the mechanism = that I have heard from so far also favor a single mechanism. So, we're = left with having to have some flexibility to support different use = cases, that need different scopes. Once we have that, we absolutely = should be careful about keeping the complexity to a minimum and that = includes the scopes. There have been several discussions about which = scopes are needed for which use cases and what should be mandatory to = implement vs. optional and I think these will result in a well thought = out, small, set of necessary scopes and an understanding of what = optional scopes we need to support some use cases and not others. Given = that we understand that different use cases will benefit from different = scopes, I'm not sure that we can get away from having a way to = explicitly assign scopes to control information. So, we get back then to the question of if we can (or should) do both = implicit and explicit scopes. If we do an implicit, default, scope, = what use case do we pick for that? Why is it different than other use = cases? How do we keep that implicit, default, scope from affecting = other cases and from confusing implementors? There were some other threads to foster discussion on specific scopes = also. I think these are good places to explore what we really need and = discussion of use cases is really helpful for those. Thanks, Eric On Jul 19, 2013, at 8:07 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi all >=20 > I come back on my mail I sent you last Tuesday on an implicit scope . = As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >=20 > Hannes has a similar concern and in his new solution for overload he = focused on a minimal mechanism where there is no more explicit scopes. = Behind this minimal mechanism, there is an implicit scope which I think = is not far from mine. >=20 > =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed.=20 >=20 > Best regards >=20 > JJacques >=20 > -----Message d'origine----- > De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 > Envoy=E9 : mardi 16 juillet 2013 11:12 > =C0 : dime@ietf.org > Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) > Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hi Ben, Eric and all >=20 >=20 > About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >=20 > Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : lundi 15 juillet 2013 01:04 > =C0 : Eric McMurry > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 >=20 > On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >=20 >>=20 >> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>=20 >>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>=20 >>>> Hi Martin, >>>>=20 >>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>=20 >>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>=20 >>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>=20 >>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>=20 >>=20 >> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >=20 > I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >=20 >> I wonder if that would satisfy the use cases that folks are thinking = of when they bring up implicit scopes? >=20 > I don't know the answer there--that's why I asked a similar question = in the previous email :-) > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Jul 19 07:23:04 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 F402B11E82B2 for ; Fri, 19 Jul 2013 07:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLeuOqFZj2+Z for ; Fri, 19 Jul 2013 07:22:39 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 214BA11E812C for ; Fri, 19 Jul 2013 07:22:35 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id o10so3520317lbi.11 for ; Fri, 19 Jul 2013 07:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8dVlBTRse1mgEkjARoU/vNtOJHqYtqIY9/zdrHnTAuI=; b=yXjohWA8EC2K53qOabSpGaPusUhsHawDncUFqfm818KMRhrjwl844An1BMqUWMVECX Pf73fx4Lj58rFffiYxGS2N/IIpT9KVBq1XJlBZk8kgcLofcikzniMA5tQc8Xd1g9NKNY SCjVWr+mQrY9h84Dnz+uJTCPqlqBgUmJ87MvRPK6fw99BpRRdwjTYFV/sFu1bZTCkTWj NkvQMpyJ69nIbqhbEBbnyWbJ00IgtyTbpK2O6SjZYCDgWko9Z+jf+nFR6jjI8Bcy6biK lsnDbSrLqXzF5ECym5+MsPIF4QatMdFBaCYGVSasyZkkms4UAicm6U0OCnRZqAyd6tTJ VaCQ== X-Received: by 10.152.3.7 with SMTP id 7mr7580528lay.66.1374243754675; Fri, 19 Jul 2013 07:22:34 -0700 (PDT) Received: from 87-93-18-125.bb.dnainternet.fi (87-93-18-125.bb.dnainternet.fi. [87.93.18.125]) by mx.google.com with ESMTPSA id p7sm6189554lbi.15.2013.07.19.07.22.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 07:22:32 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Fri, 19 Jul 2013 17:22:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <538F3F98-8A68-4D01-A213-F8202373D9A3@gmail.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 19 Jul 2013 14:23:04 -0000 On Jul 19, 2013, at 4:07 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi all >=20 > I come back on my mail I sent you last Tuesday on an implicit scope . = As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >=20 > Hannes has a similar concern and in his new solution for overload he = focused on a minimal mechanism where there is no more explicit scopes. = Behind this minimal mechanism, there is an implicit scope which I think = is not far from mine. draft-korhonen-dime-ovl-01 also had a set of scopes. When I was thinking = the set I would need I settled down to 3 for controlling who can add = overload data (and 3 other "scopes" for added information types). I am = of an opinion that this is not much, although one can get 63 = permutations out of it. - Jouni > =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed.=20 >=20 > Best regards >=20 > JJacques >=20 > -----Message d'origine----- > De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 > Envoy=E9 : mardi 16 juillet 2013 11:12 > =C0 : dime@ietf.org > Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) > Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hi Ben, Eric and all >=20 >=20 > About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >=20 > Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : lundi 15 juillet 2013 01:04 > =C0 : Eric McMurry > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 >=20 > On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >=20 >>=20 >> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>=20 >>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>=20 >>>> Hi Martin, >>>>=20 >>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>=20 >>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>=20 >>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>=20 >>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>=20 >>=20 >> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >=20 > I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >=20 >> I wonder if that would satisfy the use cases that folks are thinking = of when they bring up implicit scopes? >=20 > I don't know the answer there--that's why I asked a similar question = in the previous email :-) > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Fri Jul 19 13:49:05 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 1E8EE21F9F13 for ; Fri, 19 Jul 2013 13:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFwXIT4lKVXd for ; Fri, 19 Jul 2013 13:49:04 -0700 (PDT) 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 9C35021F9EEC for ; Fri, 19 Jul 2013 13:49:04 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-076-101.mycingular.net [166.147.76.101]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JKmvgG096967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jul 2013 15:48:58 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <2F20406A-CE59-4BEE-9310-E90DDEAB7464@gmail.com> Date: Fri, 19 Jul 2013 15:48:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41257EDA-3F60-4008-BF74-A9F4F48C58CF@nostrum.com> <7C03DB36-EBF3-45FB-AEB0-A029C55C2DB2@gmail.com> <2F20406A-CE59-4BEE-9310-E90DDEAB7464@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.76.101 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope 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, 19 Jul 2013 20:49:05 -0000 On Jul 18, 2013, at 3:54 PM, Jouni Korhonen = wrote: >> The connection scope in draft-roach-dime-overload-ctrl treats the = "Connection" scope to mean "this connection". That is, the connection on = which you receive the report. That indirectly maps to the 5-tuple of the = transport connection, but that's the transport layer's problem to figure = out. >=20 > Ack. It would be slightly more easier to make the distinction between = these > two scopes if the actual underlying Diameter functionality were = referred. As > far as I understood, connection scope allows me to differentiate a = specific > transport layer connection when multiple instances is used. Is this = correct? Yes, that is true, although I would say that the Connection scope allows = you to specifiy a specific transport layer connection, regardless of the = number of connections that might exist with the peer.= From ben@nostrum.com Fri Jul 19 13:55:32 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 E6CDE21F99A9 for ; Fri, 19 Jul 2013 13:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEluedK5brnw for ; Fri, 19 Jul 2013 13:55:31 -0700 (PDT) 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 DC00C11E8172 for ; Fri, 19 Jul 2013 13:55:25 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-076-101.mycingular.net [166.147.76.101]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JKtDA4097666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jul 2013 15:55:13 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Fri, 19 Jul 2013 15:55:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.76.101 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 19 Jul 2013 20:55:32 -0000 On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi all >=20 > I come back on my mail I sent you last Tuesday on an implicit scope . = As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >=20 > Hannes has a similar concern and in his new solution for overload he = focused on a minimal mechanism where there is no more explicit scopes. = Behind this minimal mechanism, there is an implicit scope which I think = is not far from mine. I'm not sure I understand what the implicit scope is in Hannes's draft.=20= >=20 > =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. I concur we need the most simple solution that meets the requirements. = But I think that, without at least some concept of scopes, it's going to = be very hard to come up with a mechanism that doesn't do more harm than = good. Either it will increase the impact of an overload condition by = forcing requests to be rejected unnecessarily, or it will cause clients = and relays to attempt to send requests to alternate destinations, which = are likely also overloaded. >=20 >=20 > Best regards >=20 > JJacques >=20 > -----Message d'origine----- > De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 > Envoy=E9 : mardi 16 juillet 2013 11:12 > =C0 : dime@ietf.org > Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) > Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hi Ben, Eric and all >=20 >=20 > About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >=20 > Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : lundi 15 juillet 2013 01:04 > =C0 : Eric McMurry > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 >=20 > On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >=20 >>=20 >> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>=20 >>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>=20 >>>> Hi Martin, >>>>=20 >>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>=20 >>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>=20 >>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>=20 >>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>=20 >>=20 >> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >=20 > I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >=20 >> I wonder if that would satisfy the use cases that folks are thinking = of when they bring up implicit scopes? >=20 > I don't know the answer there--that's why I asked a similar question = in the previous email :-) > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Fri Jul 19 14:09:44 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 F341D11E810D for ; Fri, 19 Jul 2013 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD8BrkgafM06 for ; Fri, 19 Jul 2013 14:09:43 -0700 (PDT) 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 DD91111E813D for ; Fri, 19 Jul 2013 14:09:42 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-076-101.mycingular.net [166.147.76.101]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JL9afK099176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jul 2013 16:09:38 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> Date: Fri, 19 Jul 2013 16:09:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E5153F.3070101@cisco.com> <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> To: Benoit Claise X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.76.101 is authenticated by a trusted mechanism) Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, dime mailing list Subject: Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 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, 19 Jul 2013 21:09:46 -0000 On Jul 16, 2013, at 8:28 AM, Eric McMurry wrote: > On Jul 16, 2013, at 4:41 , Benoit Claise wrote: >=20 >> Dear authors, >>=20 >> Thanks for the two new draft version. >>=20 >> I still see two issues. >>=20 >> 1. >>=20 >> 1.2. Causes of Overload >>=20 >> Overload occurs when an element, such as a Diameter server or = agent, >> has insufficient resources to successfully process all of the = traffic >> =20 >> it is receiving >> . >>=20 >> ... >>=20 >> External resources can include upstream Diameter nodes; for = example, >> a Diameter agent can become effectively overloaded if one or more >> upstream nodes are overloaded. While overload is not the same = thing >> as network congestion, network congestion can reduce a Diameter = nodes >> ability to process and respond to requests, thus contributing to >> overload. >>=20 >>=20 >> I'm not discussing whether or not bandwidth is an overload cause, I = note=20 >> a discrepancy in the definition. >>=20 >> "A Diameter [RFC6733] node is said to be overloaded when it has=20 >> insufficient resources to successfully process all of the Diameter=20 >> requests that it receives." >>=20 >> If there is not enough bandwidth, the application-layer Diameter node=20= >> doesn't receive the Diameter requests. Therefore, it is not = overloaded. >>=20 >> Now, there is a difference if you start to speak about a system = overload=20 >> (for the lack of a better term) where the system is composed of = client=20 >> and server. In that case, the "system" contains the link, and the=20 >> bandwidth limitation is a valid cause of system overload. >>=20 >> I hope I explained myself correctly. >>=20 >=20 > ah, thanks for catching that. Ben and I had been discussing this but = I see responding to it was lost in the shuffle. My apologies. >=20 > The definition uses the term resources, which could include a number = of things. For the case where insufficient bandwidth would prevent = overload, I think that would only be true for a very simple topology. = With multiple connections to multiple elements, agents, shared backend = resources, or any other more complex topologies, bandwidth issues could = indeed manifest into overload issues that meet the definition. >=20 > I suspect that I am not understanding your point fully though. = Perhaps Ben can take a stab if I am not making sense. >=20 I think the issue may be that we never meant for "resources" to = necessarily mean "local resources". For example, an agent could itself = become overloaded because it's not getting responses from an upstream = server. This could be simple because the downstream view of the server = appears overloaded in aggregate to downstream clients. (This is very = close to your idea of "system" overload, I think.) But the agent could = also suffer truly local overload due to queues or memory filling up, the = need to retransmit requests, etc. For the non-agent case, a server might depend on a remote database. If = network congestion causes responses from the database server to be lost = or slow down, the Diameter server can become overloaded. Would it help if we added a note to point out that the mentioned = "resources" do not necessarily have to be local to the Diameter node? [...] Thanks! Ben.= From md3135@att.com Fri Jul 19 14:18:48 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 0E05521E8088 for ; Fri, 19 Jul 2013 14:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl42e8Nbe4s4 for ; Fri, 19 Jul 2013 14:18:42 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 001E211E817C for ; Fri, 19 Jul 2013 14:18:41 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 23da9e15.77864940.9062364.00-579.25164785.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 19 Jul 2013 21:18:42 +0000 (UTC) X-MXL-Hash: 51e9ad325b985432-719a5cd7ef341d3a39bba188058835881fe65514 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 03da9e15.0.9062358.00-117.25164759.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 19 Jul 2013 21:18:41 +0000 (UTC) X-MXL-Hash: 51e9ad310927392a-dfa92e89b438de2777a98ab80dc99509f0863987 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6JLIdUm004446; Fri, 19 Jul 2013 17:18:40 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6JLIWoM004305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 17:18:34 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 19 Jul 2013 21:18:13 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Fri, 19 Jul 2013 17:18:12 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: Ac6AkPt9WmLHlk2/TcKLA1L3YPNX5P///NqAgAA3+YCAADGjAIAAIvkA//2ku2D/9k/6gIAUJ3KAgAA9VvA= Date: Fri, 19 Jul 2013 21:18:12 +0000 Message-ID: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.92.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=LoseYQF8QCEA:10 a=SwQuyvRTWPEA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=xf6OL2nRrXEA:10 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8] X-AnalysisOut: [ a=8qSefF8wAAAA:8 a=Z80JlwQ0AAAA:8 a=HlnQQvBCbjQPbIYVVd0A:] X-AnalysisOut: [9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=] X-AnalysisOut: [mHZC5r8sFEQA:10 a=0MAqpqVwYqEA:10 a=nOOCMIMK7H21xMI7:21 a=] X-AnalysisOut: [8NOtCOi6slmI9JCS:21] Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 19 Jul 2013 21:18:48 -0000 Ben/all, I believe there could be an "implicit" scope that is common to all use case= s (e.g, Application-ID). Regards, Martin -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ben= Campbell Sent: Friday, July 19, 2013 4:55 PM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thie= rry (Thierry) Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" wrote: > Hi all >=20 > I come back on my mail I sent you last Tuesday on an implicit scope . As = I said, I am concerned with the number of scopes and their combinations in = the draft-roach solution which adds complexity, and for this solution I pr= oposed to consider an implicit scope which for me should fit many cases.=20 >=20 > Hannes has a similar concern and in his new solution for overload he focu= sed on a minimal mechanism where there is no more explicit scopes. Behind = this minimal mechanism, there is an implicit scope which I think is not far= from mine. I'm not sure I understand what the implicit scope is in Hannes's draft.=20 >=20 > From these inputs, I think the group should investigate a basic version o= f the overload control mechanism which could be also part of the draft roac= h solution and see which extensions are needed. I concur we need the most simple solution that meets the requirements. But = I think that, without at least some concept of scopes, it's going to be ver= y hard to come up with a mechanism that doesn't do more harm than good. Eit= her it will increase the impact of an overload condition by forcing request= s to be rejected unnecessarily, or it will cause clients and relays to atte= mpt to send requests to alternate destinations, which are likely also overl= oaded. >=20 >=20 > Best regards >=20 > JJacques >=20 > -----Message d'origine----- > De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 > Envoy=E9 : mardi 16 juillet 2013 11:12 > =C0 : dime@ietf.org > Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith (Keith= ) > Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hi Ben, Eric and all >=20 >=20 > About the implicit scope, I am thinking to the one used for an overload i= nfo which relates to the traffic to which the message transporting this ove= rload info belongs, meaning the traffic between a Destination Host/destinat= ion realm, origin Host/origin realm, for a given Application ID. This scope= is implicitly defined by these AVPs of the message and does not require a = combination of Scope AVPs >=20 > Another point is on how to limit the number of scopes and their combinati= ons. Such a number of possibilities increase the complexity of the overload= control management, which increases the risks. The implicit scope is an an= swer to this question as it can be used instead of the other scopes such as= Destination Host, Origin Host, application ID, connection, and their combi= nations in many cases. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell > Envoy=E9 : lundi 15 juillet 2013 01:04 > =C0 : Eric McMurry > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 >=20 > On Jul 14, 2013, at 3:59 PM, Eric McMurry wrote: >=20 >>=20 >> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>=20 >>> On Jul 14, 2013, at 9:41 AM, Eric McMurry wrote= : >>>=20 >>>> Hi Martin, >>>>=20 >>>> Technically that should be possible. I have some concern about mixing= implicit and explicit scopes though. That could be confusing. I would th= ink it won't be that hard to put those two scopes into control information = they apply to.=20 >>>>=20 >>>> Perhaps others have thoughts on mixing implicit and explicit scopes? >>>=20 >>> I think this depends on what we mean by implicit scopes. Is an implicit= scope a default that is used if no scope indicators are in an overload rep= ort? Or is it a scope that is assumed to be in all reports even if not indi= cated? I think the first _might_ make sense. The second runs afoul of your = concern about mixing implicit and explicit. >>>=20 >>> In general, though, I lean towards thinking explicit is usually better.= I can see some uses for implicit, for example if an IP address is obscured= by a NAT, a node might not be able to explicitly indicate its IP address t= o a peer. But that would be more of an explicit scope indication with an im= plicit value. For example a Host scope with a value of "whatever IP address= you received this request from" >>>=20 >>=20 >> The "whatever IP you received this request from" concept could be useful= for some other scopes also. For example, whatever connection you received= this request on, or whatever application you received this request on. >=20 > I don't think there's any other way to do "connection" to mean anything b= ut "this connection". I guess we could explicitly name a 5-tuple, but I sus= pect that way leads to madness. OTOH, "this application" could just as easi= ly be named explicitly, so I'm not sure there's a benefit there. >=20 >> I wonder if that would satisfy the use cases that folks are thinking of = when they bring up implicit scopes? >=20 > I don't know the answer there--that's why I asked a similar question in t= he previous email :-) > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Fri Jul 19 14:38: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 C342021F995F for ; Fri, 19 Jul 2013 14:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSER5GIiIvQE for ; Fri, 19 Jul 2013 14:38:35 -0700 (PDT) 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 5B6F111E8194 for ; Fri, 19 Jul 2013 14:38:35 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-076-101.mycingular.net [166.147.76.101]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JLcUNB002441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jul 2013 16:38:31 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Fri, 19 Jul 2013 16:38:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.76.101 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 19 Jul 2013 21:38:36 -0000 By "implicit" scope, are we really talking about a "default" scope? That = is, a scope assumed to be active if no scope is reported, but is = overridden if any explicit scope is reported? If so, I don't object in principle. But I think the choice of a default = should be the scope that we think will be used the most often.=20 You mention Application-Id. That makes sense for a default if you expect = Application-Id to actually be selective most of the time, that is, you = expect nodes to send lots of requests with different Application-Ids to = the same destination. That's probably true if the destination is an = agent that routes request for more than one application. OTOH, do you = usually see a client send requests for more than one application on a = single transport layer connection? My kneejerk reaction is to think that the most commonly used scope will = be "connection". OTOH, Application-Id or Connection can each be indicated by a single = AVP. Do we gain much in allowing it to be defaulted? JJacques previously = mentioned "Destination Host/destination realm, origin Host/origin realm, = for a given Application ID", which is a composite that would require 4-5 = scope AVPs to express. I don't think that combination would necessarily = make a good default, but I can see one might want to be able to express = it (and more importantly, negotiate that you can accept that = combination, but not other combinations of the same scopes.) We could = always add some new scope-type that means "This destination-host, This = application-Id", etc. (I'm not suggesting we do so now, but since we = intended scopes to be extensible, we could always add that down the road = if we find the need to do so. On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" wrote: > Ben/all, >=20 > I believe there could be an "implicit" scope that is common to all use = cases (e.g, Application-ID). >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Ben Campbell > Sent: Friday, July 19, 2013 4:55 PM > To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, = Thierry (Thierry) > Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 >=20 > On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >> Hi all >>=20 >> I come back on my mail I sent you last Tuesday on an implicit scope . = As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >>=20 >> Hannes has a similar concern and in his new solution for overload he = focused on a minimal mechanism where there is no more explicit scopes. = Behind this minimal mechanism, there is an implicit scope which I think = is not far from mine. >=20 > I'm not sure I understand what the implicit scope is in Hannes's = draft.=20 >=20 >>=20 >> =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. >=20 > I concur we need the most simple solution that meets the requirements. = But I think that, without at least some concept of scopes, it's going to = be very hard to come up with a mechanism that doesn't do more harm than = good. Either it will increase the impact of an overload condition by = forcing requests to be rejected unnecessarily, or it will cause clients = and relays to attempt to send requests to alternate destinations, which = are likely also overloaded. >=20 >>=20 >>=20 >> Best regards >>=20 >> JJacques >>=20 >> -----Message d'origine----- >> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >> Envoy=E9 : mardi 16 juillet 2013 11:12 >> =C0 : dime@ietf.org >> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) >> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >>=20 >> Hi Ben, Eric and all >>=20 >>=20 >> About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >>=20 >> Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >>=20 >> Best regards >>=20 >> JJacques >>=20 >>=20 >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell >> Envoy=E9 : lundi 15 juillet 2013 01:04 >> =C0 : Eric McMurry >> Cc : dime@ietf.org >> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >>=20 >>=20 >> On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >>=20 >>>=20 >>> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>>=20 >>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>>=20 >>>>> Hi Martin, >>>>>=20 >>>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>>=20 >>>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>>=20 >>>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>>=20 >>>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>>=20 >>>=20 >>> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >>=20 >> I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >>=20 >>> I wonder if that would satisfy the use cases that folks are thinking = of when they bring up implicit scopes? >>=20 >> I don't know the answer there--that's why I asked a similar question = in the previous email :-) >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From bclaise@cisco.com Sun Jul 21 07:02:10 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 B2F5F11E80EA for ; Sun, 21 Jul 2013 07:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOT2rUtK+Pkm for ; Sun, 21 Jul 2013 07:01:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B321E808A for ; Sun, 21 Jul 2013 07:01:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LE1ljA019697; Sun, 21 Jul 2013 16:01:47 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LE0nx7000695; Sun, 21 Jul 2013 16:01:07 +0200 (CEST) Message-ID: <51EBE991.3020609@cisco.com> Date: Sun, 21 Jul 2013 16:00:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ben Campbell References: <51E5153F.3070101@cisco.com> <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020308090206000407010002" Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, dime mailing list Subject: Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 14:02:11 -0000 This is a multi-part message in MIME format. --------------020308090206000407010002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 19/07/2013 23:09, Ben Campbell wrote: > On Jul 16, 2013, at 8:28 AM, Eric McMurry wrote: > >> On Jul 16, 2013, at 4:41 , Benoit Claise wrote: >> >>> Dear authors, >>> >>> Thanks for the two new draft version. >>> >>> I still see two issues. >>> >>> 1. >>> >>> 1.2. Causes of Overload >>> >>> Overload occurs when an element, such as a Diameter server or agent, >>> has insufficient resources to successfully process all of the traffic >>> >>> it is receiving >>> . >>> >>> ... >>> >>> External resources can include upstream Diameter nodes; for example, >>> a Diameter agent can become effectively overloaded if one or more >>> upstream nodes are overloaded. While overload is not the same thing >>> as network congestion, network congestion can reduce a Diameter nodes >>> ability to process and respond to requests, thus contributing to >>> overload. >>> >>> >>> I'm not discussing whether or not bandwidth is an overload cause, I note >>> a discrepancy in the definition. >>> >>> "A Diameter [RFC6733] node is said to be overloaded when it has >>> insufficient resources to successfully process all of the Diameter >>> requests that it receives." >>> >>> If there is not enough bandwidth, the application-layer Diameter node >>> doesn't receive the Diameter requests. Therefore, it is not overloaded. >>> >>> Now, there is a difference if you start to speak about a system overload >>> (for the lack of a better term) where the system is composed of client >>> and server. In that case, the "system" contains the link, and the >>> bandwidth limitation is a valid cause of system overload. >>> >>> I hope I explained myself correctly. >>> >> ah, thanks for catching that. Ben and I had been discussing this but I see responding to it was lost in the shuffle. My apologies. >> >> The definition uses the term resources, which could include a number of things. For the case where insufficient bandwidth would prevent overload, I think that would only be true for a very simple topology. With multiple connections to multiple elements, agents, shared backend resources, or any other more complex topologies, bandwidth issues could indeed manifest into overload issues that meet the definition. >> >> I suspect that I am not understanding your point fully though. Perhaps Ben can take a stab if I am not making sense. >> > I think the issue may be that we never meant for "resources" to necessarily mean "local resources". For example, an agent could itself become overloaded because it's not getting responses from an upstream server. This could be simple because the downstream view of the server appears overloaded in aggregate to downstream clients. (This is very close to your idea of "system" overload, I think.) But the agent could also suffer truly local overload due to queues or memory filling up, the need to retransmit requests, etc. > > For the non-agent case, a server might depend on a remote database. If network congestion causes responses from the database server to be lost or slow down, the Diameter server can become overloaded. > > Would it help if we added a note to point out that the mentioned "resources" do not necessarily have to be local to the Diameter node? I was able to narrow my source of confusion to a very specific point: what is an upstream diameter node? I took this "overload" definition: Overload occurs when an element, such as a Diameter server or agent, has insufficient resources to successfully process all of the traffic _it is receiving_. Then I took this sentence: External resources can include upstream Diameter nodes; for example, a Diameter agent can become effectively overloaded if one or more upstream nodes are overloaded. While overload is not the same thing as network congestion, network congestion can reduce a Diameter nodes ability to process and respond to requests, thus contributing to overload. In my mind, I saw a picture like this: Overloaded Upstream Diameter Diameter Node Node -------------------->---------X request So I was thinking: the Diameter node (on the right, on the drawing) didn't receive the request. So according to the definition, it can't be overloaded. I guess that you had a picture like this in mind. Overloaded Upstream Diameter Diameter Node Node --------------------> request X<---------- (*) (*) the reply never arrived because the Overloaded Upstream Diameter Node is well ... overloaded After checking "Upstream" in RFC 6733, we're should be fine. Figure 7 provides an example of a message forwarded upstream by a Diameter relay. +---------+ 1. Request +---------+ 2. Request +---------+ | Access |------------>|Diameter |------------>|Diameter | | | | | | Home | | Device |<------------| Relay |<------------| Server | +---------+ 4. Answer +---------+ 3. Answer +---------+ (Missing AVP) (Missing AVP) My confusion. sorry. Regards, Benoit > [...] > > Thanks! > > Ben. > > --------------020308090206000407010002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 19/07/2013 23:09, Ben Campbell wrote:
On Jul 16, 2013, at 8:28 AM, Eric McMurry <emcmurry@computer.org> wrote:


On Jul 16, 2013, at 4:41 , Benoit Claise <bclaise@cisco.com> wrote:


Dear authors,

Thanks for the two new draft version.

I still see two issues.

1.

1.2.  Causes of Overload

   Overload occurs when an element, such as a Diameter server or agent,
   has insufficient resources to successfully process all of the traffic
   
it is receiving
.

   ...

   External resources can include upstream Diameter nodes; for example,
   a Diameter agent can become effectively overloaded if one or more
   upstream nodes are overloaded.  While overload is not the same thing
   as network congestion, network congestion can reduce a Diameter nodes
   ability to process and respond to requests, thus contributing to
   overload.


I'm not discussing whether or not bandwidth is an overload cause, I note 
a discrepancy in the definition.

 "A Diameter [RFC6733] node is said to be overloaded when it has 
insufficient resources to successfully process all of the Diameter 
requests that it receives."

If there is not enough bandwidth, the application-layer Diameter node 
doesn't receive the Diameter requests. Therefore, it is not overloaded.

Now, there is a difference if you start to speak about a system overload 
(for the lack of a better term) where the system is composed of client 
and server. In that case, the "system" contains the link, and the 
bandwidth limitation is a valid cause of system overload.

I hope I explained myself correctly.


ah, thanks for catching that.  Ben and I had been discussing this but I see responding to it was lost in the shuffle.  My apologies.

The definition uses the term resources, which could include a number of things.  For the case where insufficient bandwidth would prevent overload, I think that would only be true for a very simple topology.  With multiple connections to multiple elements, agents, shared backend resources, or any other more complex topologies, bandwidth issues could indeed manifest into overload issues that meet the definition.

I suspect that I am not understanding your point fully though.  Perhaps Ben can take a stab if I am not making sense.


I think the issue may be that we never meant for "resources" to necessarily mean "local resources". For example, an agent could itself become overloaded because it's not getting responses from an upstream server. This could be simple because the downstream view of the server appears overloaded in aggregate to downstream clients. (This is very close to your idea of "system" overload, I think.) But the agent could also suffer truly local overload due to queues or memory filling up, the need to retransmit requests, etc.

For the non-agent case, a server might depend on a remote database. If network congestion causes responses from the database server to be lost or slow down, the Diameter server can become overloaded.

Would it help if we added a note to point out that the mentioned "resources" do not necessarily have to be local to the Diameter node?
I was able to narrow my source of confusion to a very specific point: what is an upstream diameter node?
I took this "overload" definition:
   Overload occurs when an element, such as a Diameter server or agent,
   has insufficient resources to successfully process all of the traffic
   it is receiving.
Then I took this sentence:
   External resources can include upstream Diameter nodes; for example,
   a Diameter agent can become effectively overloaded if one or more
   upstream nodes are overloaded.  While overload is not the same thing
   as network congestion, network congestion can reduce a Diameter nodes
   ability to process and respond to requests, thus contributing to
   overload.
In my mind, I saw a picture like this:

                                      Overloaded
                                      Upstream                                             
                                      Diameter                                      Diameter
                                     Node                                             Node
         -------------------->---------X       
                      request 

So I was thinking: the Diameter node (on the right, on the drawing) didn't receive the request. So according to the definition, it can't be overloaded.

I guess that you had a picture like this in mind.
                                                                                            Overloaded
                                                                                            Upstream                                             
                                      Diameter                                      Diameter
                                      Node                                             Node
                                                  --------------------> request   
                                                                                   X<----------   (*)

(*) the reply never arrived because the Overloaded Upstream Diameter Node is well ... overloaded

After checking  "Upstream" in RFC 6733, we're should be fine.
    
  Figure 7 provides an example of a message forwarded upstream by a
   Diameter relay. 

       +---------+ 1. Request  +---------+ 2. Request  +---------+
       | Access  |------------>|Diameter |------------>|Diameter |
       |         |             |         |             |  Home   |
       | Device  |<------------|  Relay  |<------------| Server  |
       +---------+  4. Answer  +---------+  3. Answer  +---------+
                  (Missing AVP)           (Missing AVP)
My confusion. sorry.

Regards, Benoit
[...]

Thanks!

Ben.

--------------020308090206000407010002-- From susan.shishufeng@huawei.com Sun Jul 21 19:54:37 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 B65D421F86BE for ; Sun, 21 Jul 2013 19:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljzu4tGA0v1d for ; Sun, 21 Jul 2013 19:54:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9985021F85EB for ; Sun, 21 Jul 2013 19:54:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ69495; Mon, 22 Jul 2013 02:54:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 03:52:57 +0100 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 03:53:47 +0100 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.56]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 10:53:35 +0800 From: "Shishufeng (Susan)" To: Ben Campbell , "DOLLY, MARTIN C" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: AQHOhMhX8JEy9Fo4DUu5s9Ju3DYUG5lv/oug Date: Mon, 22 Jul 2013 02:53:34 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> In-Reply-To: <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 22 Jul 2013 02:54:37 -0000 SGVsbG8gYWxsLA0KDQpJIHdvdWxkIHN1cHBvcnQgdG8gaGF2ZSBhbiBpbXBsaWNpdCBzY29wZSBs aW1pdGVkIHRvIHdoYXQncyBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgaXRzZWxmLCBpLmUuIGFz IG1lbnRpb25lZCBieSBKSiwgc3BlY2lmaWMgYXBwbGljYXRpb24sIHNwZWNpZmljIGhvc3QsIGFu ZCBzcGVjaWZpYyBkZXN0aW5hdGlvbi4gT3IgeW91IGNhbiBjYWxsIGl0IGFzIGEgY29tYmluYXRp b24gb2YgIkRlc3RpbmF0aW9uIEhvc3QvZGVzdGluYXRpb24gcmVhbG0sIG9yaWdpbiBIb3N0L29y aWdpbiByZWFsbSwgZm9yIGEgZ2l2ZW4gQXBwbGljYXRpb24gSUQiLiBGcm9tIG15IHBvaW50IG9m IHZpZXcsIGEgdmVyeSBzaW1wbHkgdXNlIGNhc2Ugb2Ygb3ZlcmxvYWQgY29udHJvbCBmb3IgM0dQ UCBEaWFtZXRlciBhcHBsaWNhdGlvbnMgaXMgdGhhdCB0aGUgc2VydmVyIHNlbmRzIGl0cyBsb2Fk L292ZXJsb2FkIGluZm9ybWF0aW9uIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgZGVjaWRlcyB0 byB0aHJvdHRsZSBvciBub3QgbWVzc2FnZXMgcmVsYXRlZCB0byB0aGUgY29ycmVzcG9uZGluZyBh cHBsaWNhdGlvbiB0byB0aGUgc2VydmVyLiBFLmcuIGZvciAzR1BQIFM2YSwgYWZ0ZXIgdXBkYXRl IGxvY2F0aW9uIHByb2NlZHVyZSwgdGhlIE1NRSB3b3VsZCBzdG9yZSBvbmUgc3BlY2lmaWMgSFNT IGlkZW50aXR5IGZvciBlYWNoIFVFIGF0dGFjaGVkIGZvciBlYXN5IHJvdXRpbmcgb2Ygc3Vic2Vx dWVudCBtZXNzYWdlcy4gVG8gdGhpcyBNTUUsIGl0IG9ubHkgY2FyZXMgaWYgdGhpcyBIU1MgaXMg b3ZlcmxvYWRlZC4gVGhpcyBkb2VzIG5vdCBwcmV2ZW50IHRvIGRlcGxveSBEaWFtZXRlciBBZ2Vu dHMgZm9yIGxvYWQgYmFsYW5jaW5nLCB3aGljaCBjYW4gcmVkaXJlY3QgdGhlIHJlcXVlc3RzIHRv IG90aGVyIG5vbi1vdmVybG9hZGluZyBzZXJ2ZXJzIG9yIGNoYW5nZSB0aGUgbGV2ZWwgb2YgdGhl IG92ZXJsb2FkIHNpdHVhdGlvbiBvZiB0aGUgc2VydmVyLiBCdXQgdG8gdGhlIGNsaWVudCwgaXQg Y2FuIGFsd2F5cyBzZWUgb25lIHNwZWNpZmljIHNlcnZlciBhdCBhIHNwZWNpZmljIHRpbWUuDQoN CkJlc3QgUmVnYXJkcywNClN1c2FuDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6 ujogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXSANCuWPkemAgeaXtumXtDog MjAxM+W5tDfmnIgyMOaXpSA1OjM4DQrmlLbku7bkuro6IERPTExZLCBNQVJUSU4gQw0K5oqE6YCB OiBkaW1lQGlldGYub3JnOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgQkVSUlksIE5pZ2VsIChOaWdl bCk7IEJlc3NpcywgVGhpZXJyeSAoVGhpZXJyeSkNCuS4u+mimDogUmU6IFtEaW1lXSBEaWFtZXRl ciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KDQpCeSAiaW1wbGljaXQiIHNj b3BlLCBhcmUgd2UgcmVhbGx5IHRhbGtpbmcgYWJvdXQgYSAiZGVmYXVsdCIgc2NvcGU/IFRoYXQg aXMsIGEgc2NvcGUgYXNzdW1lZCB0byBiZSBhY3RpdmUgaWYgbm8gc2NvcGUgaXMgcmVwb3J0ZWQs IGJ1dCBpcyBvdmVycmlkZGVuIGlmIGFueSBleHBsaWNpdCBzY29wZSBpcyByZXBvcnRlZD8NCg0K SWYgc28sIEkgZG9uJ3Qgb2JqZWN0IGluIHByaW5jaXBsZS4gQnV0IEkgdGhpbmsgdGhlIGNob2lj ZSBvZiBhIGRlZmF1bHQgc2hvdWxkIGJlIHRoZSBzY29wZSB0aGF0IHdlIHRoaW5rIHdpbGwgYmUg dXNlZCB0aGUgbW9zdCBvZnRlbi4gDQoNCllvdSBtZW50aW9uIEFwcGxpY2F0aW9uLUlkLiBUaGF0 IG1ha2VzIHNlbnNlIGZvciBhIGRlZmF1bHQgaWYgeW91IGV4cGVjdCBBcHBsaWNhdGlvbi1JZCB0 byBhY3R1YWxseSBiZSBzZWxlY3RpdmUgbW9zdCBvZiB0aGUgdGltZSwgdGhhdCBpcywgeW91IGV4 cGVjdCBub2RlcyB0byAgc2VuZCBsb3RzIG9mIHJlcXVlc3RzIHdpdGggZGlmZmVyZW50IEFwcGxp Y2F0aW9uLUlkcyB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbi4gVGhhdCdzIHByb2JhYmx5IHRydWUg aWYgdGhlIGRlc3RpbmF0aW9uIGlzIGFuIGFnZW50IHRoYXQgcm91dGVzIHJlcXVlc3QgZm9yIG1v cmUgdGhhbiBvbmUgYXBwbGljYXRpb24uIE9UT0gsIGRvIHlvdSB1c3VhbGx5IHNlZSBhIGNsaWVu dCBzZW5kIHJlcXVlc3RzIGZvciBtb3JlIHRoYW4gb25lIGFwcGxpY2F0aW9uIG9uIGEgc2luZ2xl IHRyYW5zcG9ydCBsYXllciBjb25uZWN0aW9uPw0KDQpNeSBrbmVlamVyayByZWFjdGlvbiBpcyB0 byB0aGluayB0aGF0IHRoZSBtb3N0IGNvbW1vbmx5IHVzZWQgc2NvcGUgd2lsbCBiZSAiY29ubmVj dGlvbiIuDQoNCk9UT0gsIEFwcGxpY2F0aW9uLUlkIG9yIENvbm5lY3Rpb24gY2FuIGVhY2ggYmUg aW5kaWNhdGVkIGJ5IGEgc2luZ2xlIEFWUC4gRG8gd2UgZ2FpbiBtdWNoIGluIGFsbG93aW5nIGl0 IHRvIGJlIGRlZmF1bHRlZD8gSkphY3F1ZXMgcHJldmlvdXNseSBtZW50aW9uZWQgIkRlc3RpbmF0 aW9uIEhvc3QvZGVzdGluYXRpb24gcmVhbG0sIG9yaWdpbiBIb3N0L29yaWdpbiByZWFsbSwgZm9y IGEgZ2l2ZW4gQXBwbGljYXRpb24gSUQiLCB3aGljaCBpcyBhIGNvbXBvc2l0ZSB0aGF0IHdvdWxk IHJlcXVpcmUgNC01IHNjb3BlIEFWUHMgdG8gZXhwcmVzcy4gSSBkb24ndCB0aGluayB0aGF0IGNv bWJpbmF0aW9uIHdvdWxkIG5lY2Vzc2FyaWx5IG1ha2UgYSBnb29kIGRlZmF1bHQsIGJ1dCBJIGNh biBzZWUgb25lIG1pZ2h0IHdhbnQgdG8gYmUgYWJsZSB0byBleHByZXNzIGl0IChhbmQgbW9yZSBp bXBvcnRhbnRseSwgbmVnb3RpYXRlIHRoYXQgeW91IGNhbiBhY2NlcHQgdGhhdCBjb21iaW5hdGlv biwgYnV0IG5vdCBvdGhlciBjb21iaW5hdGlvbnMgb2YgdGhlIHNhbWUgc2NvcGVzLikgV2UgY291 bGQgYWx3YXlzIGFkZCBzb21lIG5ldyBzY29wZS10eXBlIHRoYXQgbWVhbnMgIlRoaXMgZGVzdGlu YXRpb24taG9zdCwgVGhpcyBhcHBsaWNhdGlvbi1JZCIsIGV0Yy4gKEknbSBub3Qgc3VnZ2VzdGlu ZyB3ZSBkbyBzbyBub3csIGJ1dCBzaW5jZSB3ZSBpbnRlbmRlZCBzY29wZXMgdG8gYmUgZXh0ZW5z aWJsZSwgd2UgY291bGQgYWx3YXlzIGFkZCB0aGF0IGRvd24gdGhlIHJvYWQgaWYgd2UgZmluZCB0 aGUgbmVlZCB0byBkbyBzby4NCg0KDQpPbiBKdWwgMTksIDIwMTMsIGF0IDQ6MTggUE0sICJET0xM WSwgTUFSVElOIEMiIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQoNCj4gQmVuL2FsbCwNCj4gDQo+ IEkgYmVsaWV2ZSB0aGVyZSBjb3VsZCBiZSBhbiAiaW1wbGljaXQiIHNjb3BlIHRoYXQgaXMgY29t bW9uIHRvIGFsbCB1c2UgY2FzZXMgKGUuZywgQXBwbGljYXRpb24tSUQpLg0KPiANCj4gUmVnYXJk cywNCj4gDQo+IE1hcnRpbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQmVuIENhbXBiZWxsDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxOSwgMjAxMyA0 OjU1IFBNDQo+IFRvOiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykNCj4gQ2M6 IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBkaW1lQGlldGYub3JnOyBCRVJSWSwgTmlnZWwgKE5pZ2Vs KTsgQmVzc2lzLCBUaGllcnJ5IChUaGllcnJ5KQ0KPiBTdWJqZWN0OiBSZTogW0RpbWVdIERpYW1l dGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGljaXQiIFNjb3BlDQo+IA0KPiANCj4gT24gSnVs IDE5LCAyMDEzLCBhdCA4OjA3IEFNLCAiVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FV RVMpIiA8amVhbi1qYWNxdWVzLnRyb3R0aW5AYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCj4g DQo+PiBIaSBhbGwNCj4+IA0KPj4gSSBjb21lIGJhY2sgb24gbXkgbWFpbCBJIHNlbnQgeW91IGxh c3QgVHVlc2RheSBvbiBhbiBpbXBsaWNpdCBzY29wZSAuIEFzIEkgc2FpZCwgSSBhbSBjb25jZXJu ZWQgd2l0aCB0aGUgbnVtYmVyIG9mIHNjb3BlcyBhbmQgdGhlaXIgY29tYmluYXRpb25zIGluIHRo ZSBkcmFmdC1yb2FjaCBzb2x1dGlvbiAgd2hpY2ggYWRkcyBjb21wbGV4aXR5LCBhbmQgZm9yIHRo aXMgc29sdXRpb24gSSBwcm9wb3NlZCB0byBjb25zaWRlciBhbiBpbXBsaWNpdCBzY29wZSB3aGlj aCBmb3IgbWUgc2hvdWxkIGZpdCBtYW55IGNhc2VzLiANCj4+IA0KPj4gSGFubmVzIGhhcyBhIHNp bWlsYXIgY29uY2VybiBhbmQgaW4gaGlzIG5ldyBzb2x1dGlvbiBmb3Igb3ZlcmxvYWQgaGUgZm9j dXNlZCBvbiBhIG1pbmltYWwgbWVjaGFuaXNtIHdoZXJlIHRoZXJlIGlzICBubyBtb3JlIGV4cGxp Y2l0IHNjb3Blcy4gQmVoaW5kIHRoaXMgbWluaW1hbCBtZWNoYW5pc20sIHRoZXJlIGlzIGFuIGlt cGxpY2l0IHNjb3BlIHdoaWNoIEkgdGhpbmsgaXMgbm90IGZhciBmcm9tIG1pbmUuDQo+IA0KPiBJ J20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgdGhlIGltcGxpY2l0IHNjb3BlIGlzIGluIEhh bm5lcydzIGRyYWZ0LiANCj4gDQo+PiANCj4+IEZyb20gdGhlc2UgaW5wdXRzLCBJIHRoaW5rIHRo ZSBncm91cCBzaG91bGQgaW52ZXN0aWdhdGUgYSBiYXNpYyB2ZXJzaW9uIG9mIHRoZSBvdmVybG9h ZCBjb250cm9sIG1lY2hhbmlzbSB3aGljaCBjb3VsZCBiZSBhbHNvIHBhcnQgb2YgdGhlIGRyYWZ0 IHJvYWNoIHNvbHV0aW9uIGFuZCBzZWUgd2hpY2ggZXh0ZW5zaW9ucyBhcmUgbmVlZGVkLg0KPiAN Cj4gSSBjb25jdXIgd2UgbmVlZCB0aGUgbW9zdCBzaW1wbGUgc29sdXRpb24gdGhhdCBtZWV0cyB0 aGUgcmVxdWlyZW1lbnRzLiBCdXQgSSB0aGluayB0aGF0LCB3aXRob3V0IGF0IGxlYXN0IHNvbWUg Y29uY2VwdCBvZiBzY29wZXMsIGl0J3MgZ29pbmcgdG8gYmUgdmVyeSBoYXJkIHRvIGNvbWUgdXAg d2l0aCBhIG1lY2hhbmlzbSB0aGF0IGRvZXNuJ3QgZG8gbW9yZSBoYXJtIHRoYW4gZ29vZC4gRWl0 aGVyIGl0IHdpbGwgaW5jcmVhc2UgdGhlIGltcGFjdCBvZiBhbiBvdmVybG9hZCBjb25kaXRpb24g YnkgZm9yY2luZyByZXF1ZXN0cyB0byBiZSByZWplY3RlZCB1bm5lY2Vzc2FyaWx5LCBvciBpdCB3 aWxsIGNhdXNlIGNsaWVudHMgYW5kIHJlbGF5cyB0byBhdHRlbXB0IHRvIHNlbmQgcmVxdWVzdHMg dG8gYWx0ZXJuYXRlIGRlc3RpbmF0aW9ucywgd2hpY2ggYXJlIGxpa2VseSBhbHNvIG92ZXJsb2Fk ZWQuDQo+IA0KPj4gDQo+PiANCj4+IEJlc3QgcmVnYXJkcw0KPj4gDQo+PiBKSmFjcXVlcw0KPj4g DQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERlIDogVFJPVFRJTiwgSkVBTi1K QUNRVUVTIChKRUFOLUpBQ1FVRVMpIA0KPj4gRW52b3nDqSA6IG1hcmRpIDE2IGp1aWxsZXQgMjAx MyAxMToxMg0KPj4gw4AgOiBkaW1lQGlldGYub3JnDQo+PiBDYyA6IEJFUlJZLCBOaWdlbCAoTmln ZWwpOyBCZXNzaXMsIFRoaWVycnkgKFRoaWVycnkpOyBEUkFHRSwgS2VpdGggKEtlaXRoKQ0KPj4g T2JqZXQgOiBSRTogW0RpbWVdIERpYW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGljaXQi IFNjb3BlDQo+PiANCj4+IEhpIEJlbiwgRXJpYyBhbmQgYWxsDQo+PiANCj4+IA0KPj4gQWJvdXQg dGhlIGltcGxpY2l0IHNjb3BlLCBJIGFtIHRoaW5raW5nIHRvIHRoZSBvbmUgdXNlZCBmb3IgYW4g b3ZlcmxvYWQgaW5mbyB3aGljaCByZWxhdGVzIHRvIHRoZSB0cmFmZmljIHRvIHdoaWNoIHRoZSBt ZXNzYWdlIHRyYW5zcG9ydGluZyB0aGlzIG92ZXJsb2FkIGluZm8gYmVsb25ncywgbWVhbmluZyB0 aGUgdHJhZmZpYyBiZXR3ZWVuIGEgRGVzdGluYXRpb24gSG9zdC9kZXN0aW5hdGlvbiByZWFsbSwg b3JpZ2luIEhvc3Qvb3JpZ2luIHJlYWxtLCBmb3IgYSBnaXZlbiBBcHBsaWNhdGlvbiBJRC4gVGhp cyBzY29wZSBpcyBpbXBsaWNpdGx5IGRlZmluZWQgYnkgdGhlc2UgQVZQcyBvZiB0aGUgbWVzc2Fn ZSBhbmQgZG9lcyBub3QgcmVxdWlyZSBhIGNvbWJpbmF0aW9uIG9mIFNjb3BlIEFWUHMNCj4+IA0K Pj4gQW5vdGhlciBwb2ludCBpcyBvbiBob3cgdG8gbGltaXQgdGhlIG51bWJlciBvZiBzY29wZXMg YW5kIHRoZWlyIGNvbWJpbmF0aW9ucy4gU3VjaCBhIG51bWJlciBvZiBwb3NzaWJpbGl0aWVzIGlu Y3JlYXNlIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBvdmVybG9hZCBjb250cm9sIG1hbmFnZW1lbnQs IHdoaWNoIGluY3JlYXNlcyB0aGUgcmlza3MuIFRoZSBpbXBsaWNpdCBzY29wZSBpcyBhbiBhbnN3 ZXIgdG8gdGhpcyBxdWVzdGlvbiBhcyBpdCBjYW4gYmUgdXNlZCBpbnN0ZWFkIG9mIHRoZSBvdGhl ciBzY29wZXMgc3VjaCBhcyBEZXN0aW5hdGlvbiBIb3N0LCBPcmlnaW4gSG9zdCwgYXBwbGljYXRp b24gSUQsIGNvbm5lY3Rpb24sIGFuZCB0aGVpciBjb21iaW5hdGlvbnMgaW4gbWFueSBjYXNlcy4N Cj4+IA0KPj4gQmVzdCByZWdhcmRzDQo+PiANCj4+IEpKYWNxdWVzDQo+PiANCj4+IA0KPj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6IGRpbWUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBCZW4gQ2FtcGJlbGwN Cj4+IEVudm95w6kgOiBsdW5kaSAxNSBqdWlsbGV0IDIwMTMgMDE6MDQNCj4+IMOAIDogRXJpYyBN Y011cnJ5DQo+PiBDYyA6IGRpbWVAaWV0Zi5vcmcNCj4+IE9iamV0IDogUmU6IFtEaW1lXSBEaWFt ZXRlciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KPj4gDQo+PiANCj4+IE9u IEp1bCAxNCwgMjAxMywgYXQgMzo1OSBQTSwgRXJpYyBNY011cnJ5IDxlbWNtdXJyeUBjb21wdXRl ci5vcmc+IHdyb3RlOg0KPj4gDQo+Pj4gDQo+Pj4gT24gSnVsIDE0LCAyMDEzLCBhdCAxMzowMSAs IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCj4+PiANCj4+Pj4gT24gSnVs IDE0LCAyMDEzLCBhdCA5OjQxIEFNLCBFcmljIE1jTXVycnkgPGVtY211cnJ5QGNvbXB1dGVyLm9y Zz4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gSGkgTWFydGluLA0KPj4+Pj4gDQo+Pj4+PiBUZWNobmlj YWxseSB0aGF0IHNob3VsZCBiZSBwb3NzaWJsZS4gIEkgaGF2ZSBzb21lIGNvbmNlcm4gYWJvdXQg bWl4aW5nIGltcGxpY2l0IGFuZCBleHBsaWNpdCBzY29wZXMgdGhvdWdoLiAgVGhhdCBjb3VsZCBi ZSBjb25mdXNpbmcuICBJIHdvdWxkIHRoaW5rIGl0IHdvbid0IGJlIHRoYXQgaGFyZCB0byBwdXQg dGhvc2UgdHdvIHNjb3BlcyBpbnRvIGNvbnRyb2wgaW5mb3JtYXRpb24gdGhleSBhcHBseSB0by4g DQo+Pj4+PiANCj4+Pj4+IFBlcmhhcHMgb3RoZXJzIGhhdmUgdGhvdWdodHMgb24gbWl4aW5nIGlt cGxpY2l0IGFuZCBleHBsaWNpdCBzY29wZXM/DQo+Pj4+IA0KPj4+PiBJIHRoaW5rIHRoaXMgZGVw ZW5kcyBvbiB3aGF0IHdlIG1lYW4gYnkgaW1wbGljaXQgc2NvcGVzLiBJcyBhbiBpbXBsaWNpdCBz Y29wZSBhIGRlZmF1bHQgdGhhdCBpcyB1c2VkIGlmIG5vIHNjb3BlIGluZGljYXRvcnMgYXJlIGlu IGFuIG92ZXJsb2FkIHJlcG9ydD8gT3IgaXMgaXQgYSBzY29wZSB0aGF0IGlzIGFzc3VtZWQgdG8g YmUgaW4gYWxsIHJlcG9ydHMgZXZlbiBpZiBub3QgaW5kaWNhdGVkPyBJIHRoaW5rIHRoZSBmaXJz dCBfbWlnaHRfIG1ha2Ugc2Vuc2UuIFRoZSBzZWNvbmQgcnVucyBhZm91bCBvZiB5b3VyIGNvbmNl cm4gYWJvdXQgbWl4aW5nIGltcGxpY2l0IGFuZCBleHBsaWNpdC4NCj4+Pj4gDQo+Pj4+IEluIGdl bmVyYWwsIHRob3VnaCwgSSBsZWFuIHRvd2FyZHMgdGhpbmtpbmcgZXhwbGljaXQgaXMgdXN1YWxs eSBiZXR0ZXIuIEkgY2FuIHNlZSBzb21lIHVzZXMgZm9yIGltcGxpY2l0LCBmb3IgZXhhbXBsZSBp ZiBhbiBJUCBhZGRyZXNzIGlzIG9ic2N1cmVkIGJ5IGEgTkFULCBhIG5vZGUgbWlnaHQgbm90IGJl IGFibGUgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSBpdHMgSVAgYWRkcmVzcyB0byBhIHBlZXIuIEJ1 dCB0aGF0IHdvdWxkIGJlIG1vcmUgb2YgYW4gZXhwbGljaXQgc2NvcGUgaW5kaWNhdGlvbiB3aXRo IGFuIGltcGxpY2l0IHZhbHVlLiBGb3IgZXhhbXBsZSBhIEhvc3Qgc2NvcGUgd2l0aCBhIHZhbHVl IG9mICJ3aGF0ZXZlciBJUCBhZGRyZXNzIHlvdSByZWNlaXZlZCB0aGlzIHJlcXVlc3QgZnJvbSIN Cj4+Pj4gDQo+Pj4gDQo+Pj4gVGhlICJ3aGF0ZXZlciBJUCB5b3UgcmVjZWl2ZWQgdGhpcyByZXF1 ZXN0IGZyb20iIGNvbmNlcHQgY291bGQgYmUgdXNlZnVsIGZvciBzb21lIG90aGVyIHNjb3BlcyBh bHNvLiAgRm9yIGV4YW1wbGUsIHdoYXRldmVyIGNvbm5lY3Rpb24geW91IHJlY2VpdmVkIHRoaXMg cmVxdWVzdCBvbiwgb3Igd2hhdGV2ZXIgYXBwbGljYXRpb24geW91IHJlY2VpdmVkIHRoaXMgcmVx dWVzdCBvbi4NCj4+IA0KPj4gSSBkb24ndCB0aGluayB0aGVyZSdzIGFueSBvdGhlciB3YXkgdG8g ZG8gImNvbm5lY3Rpb24iIHRvIG1lYW4gYW55dGhpbmcgYnV0ICJ0aGlzIGNvbm5lY3Rpb24iLiBJ IGd1ZXNzIHdlIGNvdWxkIGV4cGxpY2l0bHkgbmFtZSBhIDUtdHVwbGUsIGJ1dCBJIHN1c3BlY3Qg dGhhdCB3YXkgbGVhZHMgdG8gbWFkbmVzcy4gT1RPSCwgInRoaXMgYXBwbGljYXRpb24iIGNvdWxk IGp1c3QgYXMgZWFzaWx5IGJlIG5hbWVkIGV4cGxpY2l0bHksIHNvIEknbSBub3Qgc3VyZSB0aGVy ZSdzIGEgYmVuZWZpdCB0aGVyZS4NCj4+IA0KPj4+IEkgd29uZGVyIGlmIHRoYXQgd291bGQgc2F0 aXNmeSB0aGUgdXNlIGNhc2VzIHRoYXQgZm9sa3MgYXJlIHRoaW5raW5nIG9mIHdoZW4gdGhleSBi cmluZyB1cCBpbXBsaWNpdCBzY29wZXM/DQo+PiANCj4+IEkgZG9uJ3Qga25vdyB0aGUgYW5zd2Vy IHRoZXJlLS10aGF0J3Mgd2h5IEkgYXNrZWQgYSBzaW1pbGFyIHF1ZXN0aW9uIGluIHRoZSBwcmV2 aW91cyBlbWFpbCA6LSkNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBEaU1FIG1haWxpbmcgbGlzdA0KPj4gRGlNRUBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRGlNRSBtYWlsaW5nIGxpc3QN Cj4+IERpTUVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGltZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQo= From jean-jacques.trottin@alcatel-lucent.com Mon Jul 22 07:25:49 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 92A6B11E80C5 for ; Mon, 22 Jul 2013 07:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTC3Qo5Of8Rt for ; Mon, 22 Jul 2013 07:25:12 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CD13F11E8118 for ; Mon, 22 Jul 2013 07:24:13 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6MEOB0H005376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jul 2013 09:24:12 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6MENoFi021976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 16:24:10 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 22 Jul 2013 16:23:25 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: Ac6AkPt9WmLHlk2/TcKLA1L3YPNX5P///NqAgAA3+YCAADGjAIAAIvkA//2ku2D/9k/6gIATwt2AgAAGcwCAAAWmgIADfLcA//9HoXA= Date: Mon, 22 Jul 2013 14:23:25 +0000 Message-ID: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 22 Jul 2013 14:25:54 -0000 IA0KSGkgYWxsDQoNCkZyb20gdGhlIGRpZmZlcmVudCBtYWlscyBleGNoYW5nZWQgb24gdGhpcyB0 b3BpYywNCg0KSW4gIHRoZSBjdXJyZW50IHByb3Bvc2FsIHRoZXJlIGFyZSA3IHNjb3BlcyANCgni gJxDb25uZWN0aW9u4oCdIA0KCeKAnERlc3RpbmF0aW9uLVJlYWxt4oCdDQoJ4oCcQXBwbGljYXRp b24tSUTigJ0NCgnigJxEZXN0aW5hdGlvbi1Ib3N04oCdDQoJ4oCcSG9zdOKAnQ0KICAgICAg4oCc U2Vzc2lvbuKAnQ0KICAgICAg4oCcU2Vzc2lvbiBHcm91cOKAnQ0KMyBhcmUgcHJvcG9zZWQgdG8g YmUgbWFuZGF0b3J5ICgiQ29ubmVjdGlvbiIsIEFwcGxpY2F0aW9uLUlE4oCdDQoJ4oCcRGVzdGlu YXRpb24tSG9zdCIpIGFuZCBhIDggdGggKCJPcmlnaW4gSG9zdCIpIGlzIHVuZGVyIGRpc2N1c3Np b24gDQpUaGVuIGEgbGlzdCBvZiBjb21iaW5hdGlvbnMgaXMgcHJvcG9zZWQ6IA0KLSAxKihEZXN0 aW5hdGlvbi1SZWFsbSkgYW5kIDAqMShBcHBsaWNhdGlvbi1JRCkNCi0gMSooQXBwbGljYXRpb24t SUQpICBhbmQgMCoxKERlc3RpbmF0aW9uLVJlYWxtKQ0KLSAxKihBcHBsaWNhdGlvbi1JRCkgYW5k IDAqMShEZXN0aW5hdGlvbi1Ib3N0KQ0KLSAxKihBcHBsaWNhdGlvbi1JRCkgYW5kIDAqMShIb3N0 KQ0KLSAxKihBcHBsaWNhdGlvbi1JRCkgYW5kIDAqMShDb25uZWN0aW9uKQ0KLSAxKihEZXN0aW5h dGlvbi1Ib3N0KQ0KLSAxKjEoSG9zdCkNCi0gMSoxKENvbm5lY3Rpb24pDQotIDEqKFNlc3Npb24t R3JvdXApIDAqMShIb3N0IHwgQ29ubmVjdGlvbikNCi0gMSooU2Vzc2lvbikgMCoxKEhvc3QgfCBD b25uZWN0aW9uICANCg0KTXkgdGhpbmtpbmcgaXMgdGhpcyBtdWx0aXBsaWVzIHRoZSBudW1iZXIg b2YgY2FzZXMsIGFkZCBjb21wbGV4aXR5IGFuZCBpbmNyZWFzZSByaXNrcyBvZiBJT1QgaXNzdWVz IGZvciBjcml0aWNhbCBzaXR1YXRpb25zLiBXZSBhcmUgc2V2ZXJhbCB0byB0aGluayBpdCB3b3Vs ZCBiZSB3b3J0aHdoaWxlIHRvIGNvbnNpZGVyIGFuIGltcGxpY2l0IG9yIGJhc2ljIHNjb3BlIHRo YXQgd291bGQgY292ZXIgYSBsYXJnZSBudW1iZXIgb2YgdXNlIGNhc2VzIGFuZCB0byBzZWUgd2hh dCB3b3VsZCBiZSBuZWVkZWQgaW4gYWRkaXRpb24gZm9yIHNvbWUgcGFydGljdWxhciB1c2UgY2Fz ZXMuDQoNCkkgYW0gcHJvcG9zaW5nIGFuIGltcGxpY2l0IHNjb3BlLiBJdCBpcyBub3QgaW4gdGhl IGFib3ZlIGxpc3Qgb2Ygc2NvcGVzIGFuZCBvZiB0aGVpciBjb21iaW5hdGlvbnMuIFNvIGl0IHdv dWxkIGJlIGdvb2QgdG8gc2VlIGlmIGl0IGFsbG93cyB0byBjb3ZlciBtYW55IGNhc2VzLCBhcyBJ IHRoaW5rLCB0byBzaWduaWZpY2FudGx5IHJlZHVjZSB0aGUgYWJvdmUgbGlzdC4gU3V6YW4gaGFz IGhpZ2hsaWdodGVkIHRoYXQgdGhlIGltcGxpY2l0IHNjb3BlIGNvdmVycyB0aGUgTU1FIGNhc2Uu ICBEaWFtZXRlciBpcyBsYXJnZWx5IHVzZWQgZm9yIHZhcmlvdXMgYXBwbGljYXRpb25zLiAgV2hh dCBhcmUgdGhlIGtub3duIHVzZSBjYXNlcyB3aGljaCB3b3VsZCBub3QgYmUgY292ZXJlZCB3aXRo IHRoaXMgaW1wbGljaXQgc2NvcGU/IA0KSGFubmVzIGlzIGFsc28gcHJvcG9zaW5nIGEgYmFzaWMg c2NvcGUsIEkgdGhpbmsgY2xvc2UgdG8gbWluZSwgYW5kIGZvciB3aGljaCB3ZSBjYW4gaGF2ZSB0 aGUgc2FtZSBxdWVzdGlvbmluZy4NCg0KVGhlIGltcGxpY2l0IHNjb3BlIGNhbiBiZSB1c2VkIGJ5 IHNlcnZlcnMsIGNsaWVudCBhbmQgaW50ZXJtZWRpYXRlIGFnZW50cyAgdGhhdCBjYW4gYWN0IG9u IGl0IChlZyB0byBkbyBtZXNzYWdlIHRocm90dGxpbmcgaW5zdGVhZCBvZiB0aGUgY2xpZW50KS4g VG8gbm90ZSB0aGF0IHRoZSBwcmluY2lwbGUgb2YgYW4gaW1wbGljaXQgc2NvcGUgaXMgbm90IGlu Y29tcGF0aWJsZSB3aXRoIGV4cGxpY2l0IHNjb3BlcyBhbmQgYWxsb3dzIGFueSBmdXJ0aGVyIGV4 dGVuc2lvbnMgaWYgbmV3IHVzZSBjYXNlcyBhcHBlYXIgdG8gcmVxdWlyZSBzdWNoIGV4dGVuc2lv bnMNCiAgICAgICANCkJlc3QgcmVnYXJkcw0KDQpKSmFjcXVlcw0KDQoNCi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFNoaXNodWZlbmcgKFN1c2FuKQ0KRW52b3nD qcKgOiBsdW5kaSAyMiBqdWlsbGV0IDIwMTMgMDQ6NTQNCsOAwqA6IEJlbiBDYW1wYmVsbDsgRE9M TFksIE1BUlRJTiBDDQpDY8KgOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgZGltZUBpZXRmLm9yZzsg QmVzc2lzLCBUaGllcnJ5IChUaGllcnJ5KTsgQkVSUlksIE5pZ2VsIChOaWdlbCkNCk9iamV0wqA6 IFJlOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBEZWZhdWx0ICJJbXBsaWNpdCIgU2NvcGUN Cg0KSGVsbG8gYWxsLA0KDQpJIHdvdWxkIHN1cHBvcnQgdG8gaGF2ZSBhbiBpbXBsaWNpdCBzY29w ZSBsaW1pdGVkIHRvIHdoYXQncyBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgaXRzZWxmLCBpLmUu IGFzIG1lbnRpb25lZCBieSBKSiwgc3BlY2lmaWMgYXBwbGljYXRpb24sIHNwZWNpZmljIGhvc3Qs IGFuZCBzcGVjaWZpYyBkZXN0aW5hdGlvbi4gT3IgeW91IGNhbiBjYWxsIGl0IGFzIGEgY29tYmlu YXRpb24gb2YgIkRlc3RpbmF0aW9uIEhvc3QvZGVzdGluYXRpb24gcmVhbG0sIG9yaWdpbiBIb3N0 L29yaWdpbiByZWFsbSwgZm9yIGEgZ2l2ZW4gQXBwbGljYXRpb24gSUQiLiBGcm9tIG15IHBvaW50 IG9mIHZpZXcsIGEgdmVyeSBzaW1wbHkgdXNlIGNhc2Ugb2Ygb3ZlcmxvYWQgY29udHJvbCBmb3Ig M0dQUCBEaWFtZXRlciBhcHBsaWNhdGlvbnMgaXMgdGhhdCB0aGUgc2VydmVyIHNlbmRzIGl0cyBs b2FkL292ZXJsb2FkIGluZm9ybWF0aW9uIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgZGVjaWRl cyB0byB0aHJvdHRsZSBvciBub3QgbWVzc2FnZXMgcmVsYXRlZCB0byB0aGUgY29ycmVzcG9uZGlu ZyBhcHBsaWNhdGlvbiB0byB0aGUgc2VydmVyLiBFLmcuIGZvciAzR1BQIFM2YSwgYWZ0ZXIgdXBk YXRlIGxvY2F0aW9uIHByb2NlZHVyZSwgdGhlIE1NRSB3b3VsZCBzdG9yZSBvbmUgc3BlY2lmaWMg SFNTIGlkZW50aXR5IGZvciBlYWNoIFVFIGF0dGFjaGVkIGZvciBlYXN5IHJvdXRpbmcgb2Ygc3Vi c2VxdWVudCBtZXNzYWdlcy4gVG8gdGhpcyBNTUUsIGl0IG9ubHkgY2FyZXMgaWYgdGhpcyBIU1Mg aXMgb3ZlcmxvYWRlZC4gVGhpcyBkb2VzIG5vdCBwcmV2ZW50IHRvIGRlcGxveSBEaWFtZXRlciBB Z2VudHMgZm9yIGxvYWQgYmFsYW5jaW5nLCB3aGljaCBjYW4gcmVkaXJlY3QgdGhlIHJlcXVlc3Rz IHRvIG90aGVyIG5vbi1vdmVybG9hZGluZyBzZXJ2ZXJzIG9yIGNoYW5nZSB0aGUgbGV2ZWwgb2Yg dGhlIG92ZXJsb2FkIHNpdHVhdGlvbiBvZiB0aGUgc2VydmVyLiBCdXQgdG8gdGhlIGNsaWVudCwg aXQgY2FuIGFsd2F5cyBzZWUgb25lIHNwZWNpZmljIHNlcnZlciBhdCBhIHNwZWNpZmljIHRpbWUu DQoNCkJlc3QgUmVnYXJkcywNClN1c2FuDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7 tuS6ujogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXSANCuWPkemAgeaXtumX tDogMjAxM+W5tDfmnIgyMOaXpSA1OjM4DQrmlLbku7bkuro6IERPTExZLCBNQVJUSU4gQw0K5oqE 6YCBOiBkaW1lQGlldGYub3JnOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgQkVSUlksIE5pZ2VsIChO aWdlbCk7IEJlc3NpcywgVGhpZXJyeSAoVGhpZXJyeSkNCuS4u+mimDogUmU6IFtEaW1lXSBEaWFt ZXRlciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KDQpCeSAiaW1wbGljaXQi IHNjb3BlLCBhcmUgd2UgcmVhbGx5IHRhbGtpbmcgYWJvdXQgYSAiZGVmYXVsdCIgc2NvcGU/IFRo YXQgaXMsIGEgc2NvcGUgYXNzdW1lZCB0byBiZSBhY3RpdmUgaWYgbm8gc2NvcGUgaXMgcmVwb3J0 ZWQsIGJ1dCBpcyBvdmVycmlkZGVuIGlmIGFueSBleHBsaWNpdCBzY29wZSBpcyByZXBvcnRlZD8N Cg0KSWYgc28sIEkgZG9uJ3Qgb2JqZWN0IGluIHByaW5jaXBsZS4gQnV0IEkgdGhpbmsgdGhlIGNo b2ljZSBvZiBhIGRlZmF1bHQgc2hvdWxkIGJlIHRoZSBzY29wZSB0aGF0IHdlIHRoaW5rIHdpbGwg YmUgdXNlZCB0aGUgbW9zdCBvZnRlbi4gDQoNCllvdSBtZW50aW9uIEFwcGxpY2F0aW9uLUlkLiBU aGF0IG1ha2VzIHNlbnNlIGZvciBhIGRlZmF1bHQgaWYgeW91IGV4cGVjdCBBcHBsaWNhdGlvbi1J ZCB0byBhY3R1YWxseSBiZSBzZWxlY3RpdmUgbW9zdCBvZiB0aGUgdGltZSwgdGhhdCBpcywgeW91 IGV4cGVjdCBub2RlcyB0byAgc2VuZCBsb3RzIG9mIHJlcXVlc3RzIHdpdGggZGlmZmVyZW50IEFw cGxpY2F0aW9uLUlkcyB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbi4gVGhhdCdzIHByb2JhYmx5IHRy dWUgaWYgdGhlIGRlc3RpbmF0aW9uIGlzIGFuIGFnZW50IHRoYXQgcm91dGVzIHJlcXVlc3QgZm9y IG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24uIE9UT0gsIGRvIHlvdSB1c3VhbGx5IHNlZSBhIGNs aWVudCBzZW5kIHJlcXVlc3RzIGZvciBtb3JlIHRoYW4gb25lIGFwcGxpY2F0aW9uIG9uIGEgc2lu Z2xlIHRyYW5zcG9ydCBsYXllciBjb25uZWN0aW9uPw0KDQpNeSBrbmVlamVyayByZWFjdGlvbiBp cyB0byB0aGluayB0aGF0IHRoZSBtb3N0IGNvbW1vbmx5IHVzZWQgc2NvcGUgd2lsbCBiZSAiY29u bmVjdGlvbiIuDQoNCk9UT0gsIEFwcGxpY2F0aW9uLUlkIG9yIENvbm5lY3Rpb24gY2FuIGVhY2gg YmUgaW5kaWNhdGVkIGJ5IGEgc2luZ2xlIEFWUC4gRG8gd2UgZ2FpbiBtdWNoIGluIGFsbG93aW5n IGl0IHRvIGJlIGRlZmF1bHRlZD8gSkphY3F1ZXMgcHJldmlvdXNseSBtZW50aW9uZWQgIkRlc3Rp bmF0aW9uIEhvc3QvZGVzdGluYXRpb24gcmVhbG0sIG9yaWdpbiBIb3N0L29yaWdpbiByZWFsbSwg Zm9yIGEgZ2l2ZW4gQXBwbGljYXRpb24gSUQiLCB3aGljaCBpcyBhIGNvbXBvc2l0ZSB0aGF0IHdv dWxkIHJlcXVpcmUgNC01IHNjb3BlIEFWUHMgdG8gZXhwcmVzcy4gSSBkb24ndCB0aGluayB0aGF0 IGNvbWJpbmF0aW9uIHdvdWxkIG5lY2Vzc2FyaWx5IG1ha2UgYSBnb29kIGRlZmF1bHQsIGJ1dCBJ IGNhbiBzZWUgb25lIG1pZ2h0IHdhbnQgdG8gYmUgYWJsZSB0byBleHByZXNzIGl0IChhbmQgbW9y ZSBpbXBvcnRhbnRseSwgbmVnb3RpYXRlIHRoYXQgeW91IGNhbiBhY2NlcHQgdGhhdCBjb21iaW5h dGlvbiwgYnV0IG5vdCBvdGhlciBjb21iaW5hdGlvbnMgb2YgdGhlIHNhbWUgc2NvcGVzLikgV2Ug Y291bGQgYWx3YXlzIGFkZCBzb21lIG5ldyBzY29wZS10eXBlIHRoYXQgbWVhbnMgIlRoaXMgZGVz dGluYXRpb24taG9zdCwgVGhpcyBhcHBsaWNhdGlvbi1JZCIsIGV0Yy4gKEknbSBub3Qgc3VnZ2Vz dGluZyB3ZSBkbyBzbyBub3csIGJ1dCBzaW5jZSB3ZSBpbnRlbmRlZCBzY29wZXMgdG8gYmUgZXh0 ZW5zaWJsZSwgd2UgY291bGQgYWx3YXlzIGFkZCB0aGF0IGRvd24gdGhlIHJvYWQgaWYgd2UgZmlu ZCB0aGUgbmVlZCB0byBkbyBzby4NCg0KDQpPbiBKdWwgMTksIDIwMTMsIGF0IDQ6MTggUE0sICJE T0xMWSwgTUFSVElOIEMiIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQoNCj4gQmVuL2FsbCwNCj4g DQo+IEkgYmVsaWV2ZSB0aGVyZSBjb3VsZCBiZSBhbiAiaW1wbGljaXQiIHNjb3BlIHRoYXQgaXMg Y29tbW9uIHRvIGFsbCB1c2UgY2FzZXMgKGUuZywgQXBwbGljYXRpb24tSUQpLg0KPiANCj4gUmVn YXJkcywNCj4gDQo+IE1hcnRpbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQmVuIENhbXBiZWxsDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxOSwgMjAx MyA0OjU1IFBNDQo+IFRvOiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykNCj4g Q2M6IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBkaW1lQGlldGYub3JnOyBCRVJSWSwgTmlnZWwgKE5p Z2VsKTsgQmVzc2lzLCBUaGllcnJ5IChUaGllcnJ5KQ0KPiBTdWJqZWN0OiBSZTogW0RpbWVdIERp YW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGljaXQiIFNjb3BlDQo+IA0KPiANCj4gT24g SnVsIDE5LCAyMDEzLCBhdCA4OjA3IEFNLCAiVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpB Q1FVRVMpIiA8amVhbi1qYWNxdWVzLnRyb3R0aW5AYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToN Cj4gDQo+PiBIaSBhbGwNCj4+IA0KPj4gSSBjb21lIGJhY2sgb24gbXkgbWFpbCBJIHNlbnQgeW91 IGxhc3QgVHVlc2RheSBvbiBhbiBpbXBsaWNpdCBzY29wZSAuIEFzIEkgc2FpZCwgSSBhbSBjb25j ZXJuZWQgd2l0aCB0aGUgbnVtYmVyIG9mIHNjb3BlcyBhbmQgdGhlaXIgY29tYmluYXRpb25zIGlu IHRoZSBkcmFmdC1yb2FjaCBzb2x1dGlvbiAgd2hpY2ggYWRkcyBjb21wbGV4aXR5LCBhbmQgZm9y IHRoaXMgc29sdXRpb24gSSBwcm9wb3NlZCB0byBjb25zaWRlciBhbiBpbXBsaWNpdCBzY29wZSB3 aGljaCBmb3IgbWUgc2hvdWxkIGZpdCBtYW55IGNhc2VzLiANCj4+IA0KPj4gSGFubmVzIGhhcyBh IHNpbWlsYXIgY29uY2VybiBhbmQgaW4gaGlzIG5ldyBzb2x1dGlvbiBmb3Igb3ZlcmxvYWQgaGUg Zm9jdXNlZCBvbiBhIG1pbmltYWwgbWVjaGFuaXNtIHdoZXJlIHRoZXJlIGlzICBubyBtb3JlIGV4 cGxpY2l0IHNjb3Blcy4gQmVoaW5kIHRoaXMgbWluaW1hbCBtZWNoYW5pc20sIHRoZXJlIGlzIGFu IGltcGxpY2l0IHNjb3BlIHdoaWNoIEkgdGhpbmsgaXMgbm90IGZhciBmcm9tIG1pbmUuDQo+IA0K PiBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgdGhlIGltcGxpY2l0IHNjb3BlIGlzIGlu IEhhbm5lcydzIGRyYWZ0LiANCj4gDQo+PiANCj4+IEZyb20gdGhlc2UgaW5wdXRzLCBJIHRoaW5r IHRoZSBncm91cCBzaG91bGQgaW52ZXN0aWdhdGUgYSBiYXNpYyB2ZXJzaW9uIG9mIHRoZSBvdmVy bG9hZCBjb250cm9sIG1lY2hhbmlzbSB3aGljaCBjb3VsZCBiZSBhbHNvIHBhcnQgb2YgdGhlIGRy YWZ0IHJvYWNoIHNvbHV0aW9uIGFuZCBzZWUgd2hpY2ggZXh0ZW5zaW9ucyBhcmUgbmVlZGVkLg0K PiANCj4gSSBjb25jdXIgd2UgbmVlZCB0aGUgbW9zdCBzaW1wbGUgc29sdXRpb24gdGhhdCBtZWV0 cyB0aGUgcmVxdWlyZW1lbnRzLiBCdXQgSSB0aGluayB0aGF0LCB3aXRob3V0IGF0IGxlYXN0IHNv bWUgY29uY2VwdCBvZiBzY29wZXMsIGl0J3MgZ29pbmcgdG8gYmUgdmVyeSBoYXJkIHRvIGNvbWUg dXAgd2l0aCBhIG1lY2hhbmlzbSB0aGF0IGRvZXNuJ3QgZG8gbW9yZSBoYXJtIHRoYW4gZ29vZC4g RWl0aGVyIGl0IHdpbGwgaW5jcmVhc2UgdGhlIGltcGFjdCBvZiBhbiBvdmVybG9hZCBjb25kaXRp b24gYnkgZm9yY2luZyByZXF1ZXN0cyB0byBiZSByZWplY3RlZCB1bm5lY2Vzc2FyaWx5LCBvciBp dCB3aWxsIGNhdXNlIGNsaWVudHMgYW5kIHJlbGF5cyB0byBhdHRlbXB0IHRvIHNlbmQgcmVxdWVz dHMgdG8gYWx0ZXJuYXRlIGRlc3RpbmF0aW9ucywgd2hpY2ggYXJlIGxpa2VseSBhbHNvIG92ZXJs b2FkZWQuDQo+IA0KPj4gDQo+PiANCj4+IEJlc3QgcmVnYXJkcw0KPj4gDQo+PiBKSmFjcXVlcw0K Pj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERlIDogVFJPVFRJTiwgSkVB Ti1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpIA0KPj4gRW52b3nDqSA6IG1hcmRpIDE2IGp1aWxsZXQg MjAxMyAxMToxMg0KPj4gw4AgOiBkaW1lQGlldGYub3JnDQo+PiBDYyA6IEJFUlJZLCBOaWdlbCAo TmlnZWwpOyBCZXNzaXMsIFRoaWVycnkgKFRoaWVycnkpOyBEUkFHRSwgS2VpdGggKEtlaXRoKQ0K Pj4gT2JqZXQgOiBSRTogW0RpbWVdIERpYW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGlj aXQiIFNjb3BlDQo+PiANCj4+IEhpIEJlbiwgRXJpYyBhbmQgYWxsDQo+PiANCj4+IA0KPj4gQWJv dXQgdGhlIGltcGxpY2l0IHNjb3BlLCBJIGFtIHRoaW5raW5nIHRvIHRoZSBvbmUgdXNlZCBmb3Ig YW4gb3ZlcmxvYWQgaW5mbyB3aGljaCByZWxhdGVzIHRvIHRoZSB0cmFmZmljIHRvIHdoaWNoIHRo ZSBtZXNzYWdlIHRyYW5zcG9ydGluZyB0aGlzIG92ZXJsb2FkIGluZm8gYmVsb25ncywgbWVhbmlu ZyB0aGUgdHJhZmZpYyBiZXR3ZWVuIGEgRGVzdGluYXRpb24gSG9zdC9kZXN0aW5hdGlvbiByZWFs bSwgb3JpZ2luIEhvc3Qvb3JpZ2luIHJlYWxtLCBmb3IgYSBnaXZlbiBBcHBsaWNhdGlvbiBJRC4g VGhpcyBzY29wZSBpcyBpbXBsaWNpdGx5IGRlZmluZWQgYnkgdGhlc2UgQVZQcyBvZiB0aGUgbWVz c2FnZSBhbmQgZG9lcyBub3QgcmVxdWlyZSBhIGNvbWJpbmF0aW9uIG9mIFNjb3BlIEFWUHMNCj4+ IA0KPj4gQW5vdGhlciBwb2ludCBpcyBvbiBob3cgdG8gbGltaXQgdGhlIG51bWJlciBvZiBzY29w ZXMgYW5kIHRoZWlyIGNvbWJpbmF0aW9ucy4gU3VjaCBhIG51bWJlciBvZiBwb3NzaWJpbGl0aWVz IGluY3JlYXNlIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBvdmVybG9hZCBjb250cm9sIG1hbmFnZW1l bnQsIHdoaWNoIGluY3JlYXNlcyB0aGUgcmlza3MuIFRoZSBpbXBsaWNpdCBzY29wZSBpcyBhbiBh bnN3ZXIgdG8gdGhpcyBxdWVzdGlvbiBhcyBpdCBjYW4gYmUgdXNlZCBpbnN0ZWFkIG9mIHRoZSBv dGhlciBzY29wZXMgc3VjaCBhcyBEZXN0aW5hdGlvbiBIb3N0LCBPcmlnaW4gSG9zdCwgYXBwbGlj YXRpb24gSUQsIGNvbm5lY3Rpb24sIGFuZCB0aGVpciBjb21iaW5hdGlvbnMgaW4gbWFueSBjYXNl cy4NCj4+IA0KPj4gQmVzdCByZWdhcmRzDQo+PiANCj4+IEpKYWNxdWVzDQo+PiANCj4+IA0KPj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6IGRpbWUtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBCZW4gQ2FtcGJl bGwNCj4+IEVudm95w6kgOiBsdW5kaSAxNSBqdWlsbGV0IDIwMTMgMDE6MDQNCj4+IMOAIDogRXJp YyBNY011cnJ5DQo+PiBDYyA6IGRpbWVAaWV0Zi5vcmcNCj4+IE9iamV0IDogUmU6IFtEaW1lXSBE aWFtZXRlciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KPj4gDQo+PiANCj4+ IE9uIEp1bCAxNCwgMjAxMywgYXQgMzo1OSBQTSwgRXJpYyBNY011cnJ5IDxlbWNtdXJyeUBjb21w dXRlci5vcmc+IHdyb3RlOg0KPj4gDQo+Pj4gDQo+Pj4gT24gSnVsIDE0LCAyMDEzLCBhdCAxMzow MSAsIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCj4+PiANCj4+Pj4gT24g SnVsIDE0LCAyMDEzLCBhdCA5OjQxIEFNLCBFcmljIE1jTXVycnkgPGVtY211cnJ5QGNvbXB1dGVy Lm9yZz4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gSGkgTWFydGluLA0KPj4+Pj4gDQo+Pj4+PiBUZWNo bmljYWxseSB0aGF0IHNob3VsZCBiZSBwb3NzaWJsZS4gIEkgaGF2ZSBzb21lIGNvbmNlcm4gYWJv dXQgbWl4aW5nIGltcGxpY2l0IGFuZCBleHBsaWNpdCBzY29wZXMgdGhvdWdoLiAgVGhhdCBjb3Vs ZCBiZSBjb25mdXNpbmcuICBJIHdvdWxkIHRoaW5rIGl0IHdvbid0IGJlIHRoYXQgaGFyZCB0byBw dXQgdGhvc2UgdHdvIHNjb3BlcyBpbnRvIGNvbnRyb2wgaW5mb3JtYXRpb24gdGhleSBhcHBseSB0 by4gDQo+Pj4+PiANCj4+Pj4+IFBlcmhhcHMgb3RoZXJzIGhhdmUgdGhvdWdodHMgb24gbWl4aW5n IGltcGxpY2l0IGFuZCBleHBsaWNpdCBzY29wZXM/DQo+Pj4+IA0KPj4+PiBJIHRoaW5rIHRoaXMg ZGVwZW5kcyBvbiB3aGF0IHdlIG1lYW4gYnkgaW1wbGljaXQgc2NvcGVzLiBJcyBhbiBpbXBsaWNp dCBzY29wZSBhIGRlZmF1bHQgdGhhdCBpcyB1c2VkIGlmIG5vIHNjb3BlIGluZGljYXRvcnMgYXJl IGluIGFuIG92ZXJsb2FkIHJlcG9ydD8gT3IgaXMgaXQgYSBzY29wZSB0aGF0IGlzIGFzc3VtZWQg dG8gYmUgaW4gYWxsIHJlcG9ydHMgZXZlbiBpZiBub3QgaW5kaWNhdGVkPyBJIHRoaW5rIHRoZSBm aXJzdCBfbWlnaHRfIG1ha2Ugc2Vuc2UuIFRoZSBzZWNvbmQgcnVucyBhZm91bCBvZiB5b3VyIGNv bmNlcm4gYWJvdXQgbWl4aW5nIGltcGxpY2l0IGFuZCBleHBsaWNpdC4NCj4+Pj4gDQo+Pj4+IElu IGdlbmVyYWwsIHRob3VnaCwgSSBsZWFuIHRvd2FyZHMgdGhpbmtpbmcgZXhwbGljaXQgaXMgdXN1 YWxseSBiZXR0ZXIuIEkgY2FuIHNlZSBzb21lIHVzZXMgZm9yIGltcGxpY2l0LCBmb3IgZXhhbXBs ZSBpZiBhbiBJUCBhZGRyZXNzIGlzIG9ic2N1cmVkIGJ5IGEgTkFULCBhIG5vZGUgbWlnaHQgbm90 IGJlIGFibGUgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSBpdHMgSVAgYWRkcmVzcyB0byBhIHBlZXIu IEJ1dCB0aGF0IHdvdWxkIGJlIG1vcmUgb2YgYW4gZXhwbGljaXQgc2NvcGUgaW5kaWNhdGlvbiB3 aXRoIGFuIGltcGxpY2l0IHZhbHVlLiBGb3IgZXhhbXBsZSBhIEhvc3Qgc2NvcGUgd2l0aCBhIHZh bHVlIG9mICJ3aGF0ZXZlciBJUCBhZGRyZXNzIHlvdSByZWNlaXZlZCB0aGlzIHJlcXVlc3QgZnJv bSINCj4+Pj4gDQo+Pj4gDQo+Pj4gVGhlICJ3aGF0ZXZlciBJUCB5b3UgcmVjZWl2ZWQgdGhpcyBy ZXF1ZXN0IGZyb20iIGNvbmNlcHQgY291bGQgYmUgdXNlZnVsIGZvciBzb21lIG90aGVyIHNjb3Bl cyBhbHNvLiAgRm9yIGV4YW1wbGUsIHdoYXRldmVyIGNvbm5lY3Rpb24geW91IHJlY2VpdmVkIHRo aXMgcmVxdWVzdCBvbiwgb3Igd2hhdGV2ZXIgYXBwbGljYXRpb24geW91IHJlY2VpdmVkIHRoaXMg cmVxdWVzdCBvbi4NCj4+IA0KPj4gSSBkb24ndCB0aGluayB0aGVyZSdzIGFueSBvdGhlciB3YXkg dG8gZG8gImNvbm5lY3Rpb24iIHRvIG1lYW4gYW55dGhpbmcgYnV0ICJ0aGlzIGNvbm5lY3Rpb24i LiBJIGd1ZXNzIHdlIGNvdWxkIGV4cGxpY2l0bHkgbmFtZSBhIDUtdHVwbGUsIGJ1dCBJIHN1c3Bl Y3QgdGhhdCB3YXkgbGVhZHMgdG8gbWFkbmVzcy4gT1RPSCwgInRoaXMgYXBwbGljYXRpb24iIGNv dWxkIGp1c3QgYXMgZWFzaWx5IGJlIG5hbWVkIGV4cGxpY2l0bHksIHNvIEknbSBub3Qgc3VyZSB0 aGVyZSdzIGEgYmVuZWZpdCB0aGVyZS4NCj4+IA0KPj4+IEkgd29uZGVyIGlmIHRoYXQgd291bGQg c2F0aXNmeSB0aGUgdXNlIGNhc2VzIHRoYXQgZm9sa3MgYXJlIHRoaW5raW5nIG9mIHdoZW4gdGhl eSBicmluZyB1cCBpbXBsaWNpdCBzY29wZXM/DQo+PiANCj4+IEkgZG9uJ3Qga25vdyB0aGUgYW5z d2VyIHRoZXJlLS10aGF0J3Mgd2h5IEkgYXNrZWQgYSBzaW1pbGFyIHF1ZXN0aW9uIGluIHRoZSBw cmV2aW91cyBlbWFpbCA6LSkNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBEaU1FIG1haWxpbmcgbGlzdA0KPj4gRGlNRUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRGlNRSBtYWlsaW5nIGxp c3QNCj4+IERpTUVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From ben@nostrum.com Mon Jul 22 13:36:25 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 EB0B711E813A for ; Mon, 22 Jul 2013 13:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-53pizT-gwU for ; Mon, 22 Jul 2013 13:36:25 -0700 (PDT) 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 343A211E8123 for ; Mon, 22 Jul 2013 13:36:25 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-070-058.mycingular.net [166.147.70.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6MKaKGv067967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 15:36:20 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <51EBE991.3020609@cisco.com> Date: Mon, 22 Jul 2013 15:36:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6FEAA094-F6B9-43DE-B997-AD5A85D55EB9@nostrum.com> References: <51E5153F.3070101@cisco.com> <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> <51EBE991.3020609@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.70.58 is authenticated by a trusted mechanism) Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, dime mailing list Subject: Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 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, 22 Jul 2013 20:36:26 -0000 Hi Benoit, Do I read correctly that this particular issue requires no further = action? A few more comments inline: On Jul 21, 2013, at 9:00 AM, Benoit Claise wrote: > On 19/07/2013 23:09, Ben Campbell wrote: [...] >> On Jul 16, 2013, at 8:28 AM, Eric McMurry >> wrote: >>=20 >>> ah, thanks for catching that. Ben and I had been discussing this = but I see responding to it was lost in the shuffle. My apologies. >>>=20 >>> The definition uses the term resources, which could include a number = of things. For the case where insufficient bandwidth would prevent = overload, I think that would only be true for a very simple topology. = With multiple connections to multiple elements, agents, shared backend = resources, or any other more complex topologies, bandwidth issues could = indeed manifest into overload issues that meet the definition. >>>=20 >>> I suspect that I am not understanding your point fully though. = Perhaps Ben can take a stab if I am not making sense. >>>=20 >>>=20 >> I think the issue may be that we never meant for "resources" to = necessarily mean "local resources". For example, an agent could itself = become overloaded because it's not getting responses from an upstream = server. This could be simple because the downstream view of the server = appears overloaded in aggregate to downstream clients. (This is very = close to your idea of "system" overload, I think.) But the agent could = also suffer truly local overload due to queues or memory filling up, the = need to retransmit requests, etc. >>=20 >> For the non-agent case, a server might depend on a remote database. = If network congestion causes responses from the database server to be = lost or slow down, the Diameter server can become overloaded. >>=20 >> Would it help if we added a note to point out that the mentioned = "resources" do not necessarily have to be local to the Diameter node? >>=20 > I was able to narrow my source of confusion to a very specific point: = what is an upstream diameter node? > I took this "overload" definition: > Overload occurs when an element, such as a Diameter server or = agent, > has insufficient resources to successfully process all of the = traffic > =20 > it is receiving. > Then I took this sentence: > External resources can include upstream Diameter nodes; for = example, > a Diameter agent can become effectively overloaded if one or more > upstream nodes are overloaded. While overload is not the same = thing > as network congestion, network congestion can reduce a Diameter = nodes > ability to process and respond to requests, thus contributing to > overload. >=20 > In my mind, I saw a picture like this: >=20 > Overloaded > Upstream = =20 > Diameter = Diameter > Node = Node=20 > -------------------->---------X =20 > request =20 >=20 > So I was thinking: the Diameter node (on the right, on the drawing) = didn't receive the request. So according to the definition, it can't be = overloaded. I agree that the node on the right is not overloaded in this example. = But if the one on the left is an agent, the fact that transactions are = failing between it and the node on the right may reduce it's ability to = handle inbound requests from clients. >=20 > I guess that you had a picture like this in mind. > = Overloaded > = Upstream = =20 > Diameter = Diameter > Node = Node=20 > = --------------------> request =20 > = X<---------- (*) >=20 > (*) the reply never arrived because the Overloaded Upstream Diameter = Node is well ... overloaded That is one possible case. A particularly bad one, even, since the node = on the left is likely to start retrying requests. Another example would be when a node depends on a non-Diameter remote = resource. Imagine the same picture as the previous one, but the node on = the right is a database server. If there's network congestion between = the Diameter node and the database server, the Diameter node may not be = able to operate at normal capacity. >=20 > After checking "Upstream" in RFC 6733, we're should be fine. > =20 > Figure 7 provides an example of a message forwarded upstream by a > Diameter relay.=20 >=20 > +---------+ 1. Request +---------+ 2. Request +---------+ > | Access |------------>|Diameter |------------>|Diameter | > | | | | | Home | > | Device |<------------| Relay |<------------| Server | > +---------+ 4. Answer +---------+ 3. Answer +---------+ > (Missing AVP) (Missing AVP) >=20 > My confusion. sorry. No Problem--It seems like 6733 uses "upstream" and "downstream" = differently than I am used to. (Same with "client" and "server"). Thanks! Ben. From ben@nostrum.com Mon Jul 22 13:54:19 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 DBE0811E80DF for ; Mon, 22 Jul 2013 13:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ5hk6pM-Nh5 for ; Mon, 22 Jul 2013 13:54:18 -0700 (PDT) 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 5619B11E80D3 for ; Mon, 22 Jul 2013 13:54:18 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-070-058.mycingular.net [166.147.70.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6MKsBTB069847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 15:54:12 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Mon, 22 Jul 2013 15:54:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B221313-D312-4C2D-AE2E-C075429D241C@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.70.58 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 22 Jul 2013 20:54:20 -0000 On Jul 22, 2013, at 9:23 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 > Hi all >=20 > =46rom the different mails exchanged on this topic, >=20 > In the current proposal there are 7 scopes=20 > =E2=80=9CConnection=E2=80=9D=20 > =E2=80=9CDestination-Realm=E2=80=9D > =E2=80=9CApplication-ID=E2=80=9D > =E2=80=9CDestination-Host=E2=80=9D > =E2=80=9CHost=E2=80=9D > =E2=80=9CSession=E2=80=9D > =E2=80=9CSession Group=E2=80=9D > 3 are proposed to be mandatory ("Connection", Application-ID=E2=80=9D > =E2=80=9CDestination-Host") and a 8 th ("Origin Host") is under = discussion We would not oppose reducing the number of "mandatory" scopes. I'm not = sure any really need to be mandatory, as long as you include at least = one, and have a way to declare what scopes you are willing to receive. >=20 > Then a list of combinations is proposed:=20 > - 1*(Destination-Realm) and 0*1(Application-ID) > - 1*(Application-ID) and 0*1(Destination-Realm) > - 1*(Application-ID) and 0*1(Destination-Host) > - 1*(Application-ID) and 0*1(Host) > - 1*(Application-ID) and 0*1(Connection) > - 1*(Destination-Host) > - 1*1(Host) > - 1*1(Connection) > - 1*(Session-Group) 0*1(Host | Connection) > - 1*(Session) 0*1(Host | Connection =20 >=20 > My thinking is this multiplies the number of cases, add complexity and = increase risks of IOT issues for critical situations. We are several to = think it would be worthwhile to consider an implicit or basic scope that = would cover a large number of use cases and to see what would be needed = in addition for some particular use cases. >=20 > I am proposing an implicit scope. It is not in the above list of = scopes and of their combinations. So it would be good to see if it = allows to cover many cases, as I think, to significantly reduce the = above list. Suzan has highlighted that the implicit scope covers the MME = case. Diameter is largely used for various applications. What are the = known use cases which would not be covered with this implicit scope?=20 > Hannes is also proposing a basic scope, I think close to mine, and for = which we can have the same questioning. What scope is Hannes proposing? I didn't find that in the drafts, but = may have missed something. >=20 > The implicit scope can be used by servers, client and intermediate = agents that can act on it (eg to do message throttling instead of the = client). To note that the principle of an implicit scope is not = incompatible with explicit scopes and allows any further extensions if = new use cases appear to require such extensions Can you elaborate on what you mean by an implicit scope? The two things = I can think of is 1) a scope that is considered active if no scope is = included in the message (i.e. a "default" scope), or 2) a scope that has = an implicit value derived from other characteristics of the request that = carries it (e.g. "Connection" takes it's value from the transport layer = connection on which the request arrives, rather than from an explicit = value that names the connection.) Or do you mean something else = entirely? Thanks! Ben. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Shishufeng (Susan) > Envoy=C3=A9 : lundi 22 juillet 2013 04:54 > =C3=80 : Ben Campbell; DOLLY, MARTIN C > Cc : DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); = BERRY, Nigel (Nigel) > Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hello all, >=20 > I would support to have an implicit scope limited to what's contained = in the message itself, i.e. as mentioned by JJ, specific application, = specific host, and specific destination. Or you can call it as a = combination of "Destination Host/destination realm, origin Host/origin = realm, for a given Application ID". =46rom my point of view, a very = simply use case of overload control for 3GPP Diameter applications is = that the server sends its load/overload information to the client, the = client decides to throttle or not messages related to the corresponding = application to the server. E.g. for 3GPP S6a, after update location = procedure, the MME would store one specific HSS identity for each UE = attached for easy routing of subsequent messages. To this MME, it only = cares if this HSS is overloaded. This does not prevent to deploy = Diameter Agents for load balancing, which can redirect the requests to = other non-overloading servers or change the level of the overload = situation of the server. But to the client, it can always see one = specific server at a specific time. >=20 > Best Regards, > Susan >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8820=E6=97=A5= 5:38 > =E6=94=B6=E4=BB=B6=E4=BA=BA: DOLLY, MARTIN C > =E6=8A=84=E9=80=81: dime@ietf.org; DRAGE, Keith (Keith); BERRY, Nigel = (Nigel); Bessis, Thierry (Thierry) > =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >=20 > By "implicit" scope, are we really talking about a "default" scope? = That is, a scope assumed to be active if no scope is reported, but is = overridden if any explicit scope is reported? >=20 > If so, I don't object in principle. But I think the choice of a = default should be the scope that we think will be used the most often.=20= >=20 > You mention Application-Id. That makes sense for a default if you = expect Application-Id to actually be selective most of the time, that = is, you expect nodes to send lots of requests with different = Application-Ids to the same destination. That's probably true if the = destination is an agent that routes request for more than one = application. OTOH, do you usually see a client send requests for more = than one application on a single transport layer connection? >=20 > My kneejerk reaction is to think that the most commonly used scope = will be "connection". >=20 > OTOH, Application-Id or Connection can each be indicated by a single = AVP. Do we gain much in allowing it to be defaulted? JJacques previously = mentioned "Destination Host/destination realm, origin Host/origin realm, = for a given Application ID", which is a composite that would require 4-5 = scope AVPs to express. I don't think that combination would necessarily = make a good default, but I can see one might want to be able to express = it (and more importantly, negotiate that you can accept that = combination, but not other combinations of the same scopes.) We could = always add some new scope-type that means "This destination-host, This = application-Id", etc. (I'm not suggesting we do so now, but since we = intended scopes to be extensible, we could always add that down the road = if we find the need to do so. >=20 >=20 > On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" wrote: >=20 >> Ben/all, >>=20 >> I believe there could be an "implicit" scope that is common to all = use cases (e.g, Application-ID). >>=20 >> Regards, >>=20 >> Martin >>=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Ben Campbell >> Sent: Friday, July 19, 2013 4:55 PM >> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >> Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); = Bessis, Thierry (Thierry) >> Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope >>=20 >>=20 >> On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>=20 >>> Hi all >>>=20 >>> I come back on my mail I sent you last Tuesday on an implicit scope = . As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >>>=20 >>> Hannes has a similar concern and in his new solution for overload he = focused on a minimal mechanism where there is no more explicit scopes. = Behind this minimal mechanism, there is an implicit scope which I think = is not far from mine. >>=20 >> I'm not sure I understand what the implicit scope is in Hannes's = draft.=20 >>=20 >>>=20 >>> =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. >>=20 >> I concur we need the most simple solution that meets the = requirements. But I think that, without at least some concept of scopes, = it's going to be very hard to come up with a mechanism that doesn't do = more harm than good. Either it will increase the impact of an overload = condition by forcing requests to be rejected unnecessarily, or it will = cause clients and relays to attempt to send requests to alternate = destinations, which are likely also overloaded. >>=20 >>>=20 >>>=20 >>> Best regards >>>=20 >>> JJacques >>>=20 >>> -----Message d'origine----- >>> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>> Envoy=C3=A9 : mardi 16 juillet 2013 11:12 >>> =C3=80 : dime@ietf.org >>> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) >>> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >>>=20 >>> Hi Ben, Eric and all >>>=20 >>>=20 >>> About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >>>=20 >>> Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >>>=20 >>> Best regards >>>=20 >>> JJacques >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell >>> Envoy=C3=A9 : lundi 15 juillet 2013 01:04 >>> =C3=80 : Eric McMurry >>> Cc : dime@ietf.org >>> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>=20 >>>=20 >>> On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >>>=20 >>>>=20 >>>> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>>>=20 >>>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>>>=20 >>>>>> Hi Martin, >>>>>>=20 >>>>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>>>=20 >>>>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>>>=20 >>>>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>>>=20 >>>>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>>>=20 >>>>=20 >>>> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >>>=20 >>> I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >>>=20 >>>> I wonder if that would satisfy the use cases that folks are = thinking of when they bring up implicit scopes? >>>=20 >>> I don't know the answer there--that's why I asked a similar question = in the previous email :-) >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Mon Jul 22 14:09:05 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 2D2BB11E80D3 for ; Mon, 22 Jul 2013 14:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1Y1tLVuggjR for ; Mon, 22 Jul 2013 14:09:04 -0700 (PDT) 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 DFAFA11E8123 for ; Mon, 22 Jul 2013 14:09:03 -0700 (PDT) Received: from [172.20.10.7] (mobile-166-147-070-058.mycingular.net [166.147.70.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6ML7suB071323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 16:07:55 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> Date: Mon, 22 Jul 2013 16:07:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> To: Shishufeng (Susan) X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 166.147.70.58 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 22 Jul 2013 21:09:05 -0000 Hi Susan, When you say "implicit" scope, do you mean a default? (that is, one that = applies if no scope is explicitly included)? I'm not opposed to having = such a comment, but I think we need to look more closely at how Diameter = servers tend to actually be deployed, and where we save complexity. = Realm + Application + Destination-Host + Origin-Host is a fairly complex = scope. But the complexity is not in how you express it on the = wire--that's pretty easy. It's also not how you interpret the = scope--that's a one time action per overload report. The really hard = part is the decision function that the reacting node applies to every = single request to determine if the scope applies to it. And that's true = whether the scope is implicitly or explicitly included in an overload = report. It seems to me that if we define a default scope, it should be both = commonly used and simple. The one that you and JJ have proposed may be = common, but it's not simple. I think this needs more analysis, but so = far I think that "Connection" is the strongest candidate for being both = common and simple. On Jul 21, 2013, at 9:53 PM, Shishufeng (Susan) = wrote: > Hello all, >=20 > I would support to have an implicit scope limited to what's contained = in the message itself, i.e. as mentioned by JJ, specific application, = specific host, and specific destination. Or you can call it as a = combination of "Destination Host/destination realm, origin Host/origin = realm, for a given Application ID". =46rom my point of view, a very = simply use case of overload control for 3GPP Diameter applications is = that the server sends its load/overload information to the client, the = client decides to throttle or not messages related to the corresponding = application to the server. E.g. for 3GPP S6a, after update location = procedure, the MME would store one specific HSS identity for each UE = attached for easy routing of subsequent messages. To this MME, it only = cares if this HSS is overloaded. This does not prevent to deploy = Diameter Agents for load balancing, which can redirect the requests to = other non-overloading servers or change the level of the overload = situation of the server. But to the client, it can always see one = specific server at a specific time. >=20 > Best Regards, > Susan >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8820=E6=97=A5= 5:38 > =E6=94=B6=E4=BB=B6=E4=BA=BA: DOLLY, MARTIN C > =E6=8A=84=E9=80=81: dime@ietf.org; DRAGE, Keith (Keith); BERRY, Nigel = (Nigel); Bessis, Thierry (Thierry) > =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >=20 > By "implicit" scope, are we really talking about a "default" scope? = That is, a scope assumed to be active if no scope is reported, but is = overridden if any explicit scope is reported? >=20 > If so, I don't object in principle. But I think the choice of a = default should be the scope that we think will be used the most often.=20= >=20 > You mention Application-Id. That makes sense for a default if you = expect Application-Id to actually be selective most of the time, that = is, you expect nodes to send lots of requests with different = Application-Ids to the same destination. That's probably true if the = destination is an agent that routes request for more than one = application. OTOH, do you usually see a client send requests for more = than one application on a single transport layer connection? >=20 > My kneejerk reaction is to think that the most commonly used scope = will be "connection". >=20 > OTOH, Application-Id or Connection can each be indicated by a single = AVP. Do we gain much in allowing it to be defaulted? JJacques previously = mentioned "Destination Host/destination realm, origin Host/origin realm, = for a given Application ID", which is a composite that would require 4-5 = scope AVPs to express. I don't think that combination would necessarily = make a good default, but I can see one might want to be able to express = it (and more importantly, negotiate that you can accept that = combination, but not other combinations of the same scopes.) We could = always add some new scope-type that means "This destination-host, This = application-Id", etc. (I'm not suggesting we do so now, but since we = intended scopes to be extensible, we could always add that down the road = if we find the need to do so. >=20 >=20 > On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" wrote: >=20 >> Ben/all, >>=20 >> I believe there could be an "implicit" scope that is common to all = use cases (e.g, Application-ID). >>=20 >> Regards, >>=20 >> Martin >>=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Ben Campbell >> Sent: Friday, July 19, 2013 4:55 PM >> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >> Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); = Bessis, Thierry (Thierry) >> Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope >>=20 >>=20 >> On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>=20 >>> Hi all >>>=20 >>> I come back on my mail I sent you last Tuesday on an implicit scope = . As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >>>=20 >>> Hannes has a similar concern and in his new solution for overload he = focused on a minimal mechanism where there is no more explicit scopes. = Behind this minimal mechanism, there is an implicit scope which I think = is not far from mine. >>=20 >> I'm not sure I understand what the implicit scope is in Hannes's = draft.=20 >>=20 >>>=20 >>> =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. >>=20 >> I concur we need the most simple solution that meets the = requirements. But I think that, without at least some concept of scopes, = it's going to be very hard to come up with a mechanism that doesn't do = more harm than good. Either it will increase the impact of an overload = condition by forcing requests to be rejected unnecessarily, or it will = cause clients and relays to attempt to send requests to alternate = destinations, which are likely also overloaded. >>=20 >>>=20 >>>=20 >>> Best regards >>>=20 >>> JJacques >>>=20 >>> -----Message d'origine----- >>> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>> Envoy=C3=A9 : mardi 16 juillet 2013 11:12 >>> =C3=80 : dime@ietf.org >>> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) >>> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >>>=20 >>> Hi Ben, Eric and all >>>=20 >>>=20 >>> About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >>>=20 >>> Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >>>=20 >>> Best regards >>>=20 >>> JJacques >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell >>> Envoy=C3=A9 : lundi 15 juillet 2013 01:04 >>> =C3=80 : Eric McMurry >>> Cc : dime@ietf.org >>> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>=20 >>>=20 >>> On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >>>=20 >>>>=20 >>>> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>>>=20 >>>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>>>=20 >>>>>> Hi Martin, >>>>>>=20 >>>>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>>>=20 >>>>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>>>=20 >>>>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>>>=20 >>>>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>>>=20 >>>>=20 >>>> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >>>=20 >>> I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >>>=20 >>>> I wonder if that would satisfy the use cases that folks are = thinking of when they bring up implicit scopes? >>>=20 >>> I don't know the answer there--that's why I asked a similar question = in the previous email :-) >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 From susan.shishufeng@huawei.com Tue Jul 23 00:58:24 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 2CBCB21E8084 for ; Tue, 23 Jul 2013 00:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8-roJC9ZyMh for ; Tue, 23 Jul 2013 00:58:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 09BB521E8063 for ; Tue, 23 Jul 2013 00:58:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR87341; Tue, 23 Jul 2013 07:58:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 08:57:29 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 08:57:38 +0100 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.56]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 15:57:10 +0800 From: "Shishufeng (Susan)" To: Ben Campbell Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: AQHOhMhX8JEy9Fo4DUu5s9Ju3DYUG5lv/ouggACw0QCAATK70A== Date: Tue, 23 Jul 2013 07:57:08 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> In-Reply-To: <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: [Dime] =?utf-8?b?562U5aSNOiAgRGlhbWV0ZXIgT3ZlcmxvYWQgLSBEZWZhdWx0?= =?utf-8?q?_=22Implicit=22_Scope?= 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, 23 Jul 2013 07:58:24 -0000 SGkgQmVuLA0KDQpJJ20gbm90IHN1cmUgaWYgImltcGxpY2l0IiBtZWFucyAiZGVmYXVsdCIsIGJ1 dCBzaG91bGQgYmUgdmVyeSBzaW1pbGFyIHRvIGVhY2ggb3RoZXIgb24gdGhpcyBwb2ludC4NCg0K SW4gbXkgdW5kZXJzdGFuZGluZywgIkNvbm5lY3Rpb24iIHNjb3BlIGZvY3VzIG9uIHRyYW5zcG9y dCBjb25uZWN0aW9uIHdoaWNoIGlzIGxpbWl0ZWQgYmV0d2VlbiB0d28gYWRqYWNlbnQgcGVlcnMu IFdoaWxlIGluIDNHUFAgRGlhbWV0ZXIgYXBwbGljYXRpb25zLCB0aGUgaW1wb3J0YW50IHRoaW5n IGZvciBvdmVybG9hZCBjb250cm9sIGlzIHRvIGV4Y2hhbmdlIGxvYWQvb3ZlcmxvYWQgYmV0d2Vl biBjbGllbnQgYW5kIHNlcnZlciBmb3Igd2hpY2ggdGhlcmUgbWlnaHQgbm90IGJlIGRpcmVjdCB0 cmFuc3BvcnQgY29ubmVjdGlvbi4gDQoNClRvIG1ha2UgdGhpbmdzIHNpbXBsZSBhbmQgdGhlIG1l Y2hhbmlzbSBkZWZpbmVkIGluIElFVEYgbW9yZSBjb21tb24sIEkgd291bGQgcHJvcG9zZSB0byBu b3QgaGF2ZSBhbnkgc2NvcGUgbWFuZGF0ZWQgYW5kIGxlYXZlIGl0IGZvciBhcHBsaWNhdGlvbnMg dG8gZGVjaWRlIGlmIGV4cGxpY2l0IHNjb3BlKHMpIGlzKGFyZSkgbmVlZGVkIG9yIGFuIGltcGxp Y2l0IHNjb3BlIGNhbiBiZSBhcHBsaWVkLg0KDQpCZXN0IFJlZ2FyZHMsDQpTdXNhbg0KDQotLS0t LemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBu b3N0cnVtLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMjPml6UgNTowOA0K5pS25Lu2 5Lq6OiBTaGlzaHVmZW5nIChTdXNhbikNCuaKhOmAgTogRE9MTFksIE1BUlRJTiBDOyBkaW1lQGll dGYub3JnOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgQkVSUlksIE5pZ2VsIChOaWdlbCk7IEJlc3Np cywgVGhpZXJyeSAoVGhpZXJyeSkNCuS4u+mimDogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9h ZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KDQpIaSBTdXNhbiwNCg0KV2hlbiB5b3Ugc2F5 ICJpbXBsaWNpdCIgc2NvcGUsIGRvIHlvdSBtZWFuIGEgZGVmYXVsdD8gKHRoYXQgaXMsIG9uZSB0 aGF0IGFwcGxpZXMgaWYgbm8gc2NvcGUgaXMgZXhwbGljaXRseSBpbmNsdWRlZCk/IEknbSBub3Qg b3Bwb3NlZCB0byBoYXZpbmcgc3VjaCBhIGNvbW1lbnQsIGJ1dCBJIHRoaW5rIHdlIG5lZWQgdG8g bG9vayBtb3JlIGNsb3NlbHkgYXQgaG93IERpYW1ldGVyIHNlcnZlcnMgdGVuZCB0byBhY3R1YWxs eSBiZSBkZXBsb3llZCwgYW5kIHdoZXJlIHdlIHNhdmUgY29tcGxleGl0eS4gUmVhbG0gKyBBcHBs aWNhdGlvbiArIERlc3RpbmF0aW9uLUhvc3QgKyBPcmlnaW4tSG9zdCBpcyBhIGZhaXJseSBjb21w bGV4IHNjb3BlLiBCdXQgdGhlIGNvbXBsZXhpdHkgaXMgbm90IGluIGhvdyB5b3UgZXhwcmVzcyBp dCBvbiB0aGUgd2lyZS0tdGhhdCdzIHByZXR0eSBlYXN5LiBJdCdzIGFsc28gbm90IGhvdyB5b3Ug aW50ZXJwcmV0IHRoZSBzY29wZS0tdGhhdCdzIGEgb25lIHRpbWUgYWN0aW9uIHBlciBvdmVybG9h ZCByZXBvcnQuIFRoZSByZWFsbHkgaGFyZCBwYXJ0IGlzIHRoZSBkZWNpc2lvbiBmdW5jdGlvbiB0 aGF0IHRoZSByZWFjdGluZyBub2RlIGFwcGxpZXMgdG8gZXZlcnkgc2luZ2xlIHJlcXVlc3QgdG8g ZGV0ZXJtaW5lIGlmIHRoZSBzY29wZSBhcHBsaWVzIHRvIGl0LiBBbmQgdGhhdCdzIHRydWUgd2hl dGhlciB0aGUgc2NvcGUgaXMgaW1wbGljaXRseSBvciBleHBsaWNpdGx5IGluY2x1ZGVkIGluIGFu IG92ZXJsb2FkIHJlcG9ydC4NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBpZiB3ZSBkZWZpbmUgYSBk ZWZhdWx0IHNjb3BlLCBpdCBzaG91bGQgYmUgYm90aCBjb21tb25seSB1c2VkIGFuZCBzaW1wbGUu IFRoZSBvbmUgdGhhdCB5b3UgYW5kIEpKIGhhdmUgcHJvcG9zZWQgbWF5IGJlIGNvbW1vbiwgYnV0 IGl0J3Mgbm90IHNpbXBsZS4gSSB0aGluayB0aGlzIG5lZWRzIG1vcmUgYW5hbHlzaXMsIGJ1dCBz byBmYXIgSSB0aGluayB0aGF0ICJDb25uZWN0aW9uIiBpcyB0aGUgc3Ryb25nZXN0IGNhbmRpZGF0 ZSBmb3IgYmVpbmcgYm90aCBjb21tb24gYW5kIHNpbXBsZS4NCg0KDQoNCk9uIEp1bCAyMSwgMjAx MywgYXQgOTo1MyBQTSwgU2hpc2h1ZmVuZyAoU3VzYW4pIDxzdXNhbi5zaGlzaHVmZW5nQGh1YXdl aS5jb20+IHdyb3RlOg0KDQo+IEhlbGxvIGFsbCwNCj4gDQo+IEkgd291bGQgc3VwcG9ydCB0byBo YXZlIGFuIGltcGxpY2l0IHNjb3BlIGxpbWl0ZWQgdG8gd2hhdCdzIGNvbnRhaW5lZCBpbiB0aGUg bWVzc2FnZSBpdHNlbGYsIGkuZS4gYXMgbWVudGlvbmVkIGJ5IEpKLCBzcGVjaWZpYyBhcHBsaWNh dGlvbiwgc3BlY2lmaWMgaG9zdCwgYW5kIHNwZWNpZmljIGRlc3RpbmF0aW9uLiBPciB5b3UgY2Fu IGNhbGwgaXQgYXMgYSBjb21iaW5hdGlvbiBvZiAiRGVzdGluYXRpb24gSG9zdC9kZXN0aW5hdGlv biByZWFsbSwgb3JpZ2luIEhvc3Qvb3JpZ2luIHJlYWxtLCBmb3IgYSBnaXZlbiBBcHBsaWNhdGlv biBJRCIuIEZyb20gbXkgcG9pbnQgb2YgdmlldywgYSB2ZXJ5IHNpbXBseSB1c2UgY2FzZSBvZiBv dmVybG9hZCBjb250cm9sIGZvciAzR1BQIERpYW1ldGVyIGFwcGxpY2F0aW9ucyBpcyB0aGF0IHRo ZSBzZXJ2ZXIgc2VuZHMgaXRzIGxvYWQvb3ZlcmxvYWQgaW5mb3JtYXRpb24gdG8gdGhlIGNsaWVu dCwgdGhlIGNsaWVudCBkZWNpZGVzIHRvIHRocm90dGxlIG9yIG5vdCBtZXNzYWdlcyByZWxhdGVk IHRvIHRoZSBjb3JyZXNwb25kaW5nIGFwcGxpY2F0aW9uIHRvIHRoZSBzZXJ2ZXIuIEUuZy4gZm9y IDNHUFAgUzZhLCBhZnRlciB1cGRhdGUgbG9jYXRpb24gcHJvY2VkdXJlLCB0aGUgTU1FIHdvdWxk IHN0b3JlIG9uZSBzcGVjaWZpYyBIU1MgaWRlbnRpdHkgZm9yIGVhY2ggVUUgYXR0YWNoZWQgZm9y IGVhc3kgcm91dGluZyBvZiBzdWJzZXF1ZW50IG1lc3NhZ2VzLiBUbyB0aGlzIE1NRSwgaXQgb25s eSBjYXJlcyBpZiB0aGlzIEhTUyBpcyBvdmVybG9hZGVkLiBUaGlzIGRvZXMgbm90IHByZXZlbnQg dG8gZGVwbG95IERpYW1ldGVyIEFnZW50cyBmb3IgbG9hZCBiYWxhbmNpbmcsIHdoaWNoIGNhbiBy ZWRpcmVjdCB0aGUgcmVxdWVzdHMgdG8gb3RoZXIgbm9uLW92ZXJsb2FkaW5nIHNlcnZlcnMgb3Ig Y2hhbmdlIHRoZSBsZXZlbCBvZiB0aGUgb3ZlcmxvYWQgc2l0dWF0aW9uIG9mIHRoZSBzZXJ2ZXIu IEJ1dCB0byB0aGUgY2xpZW50LCBpdCBjYW4gYWx3YXlzIHNlZSBvbmUgc3BlY2lmaWMgc2VydmVy IGF0IGEgc3BlY2lmaWMgdGltZS4NCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gU3VzYW4NCj4gDQo+ IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBCZW4gQ2FtcGJlbGwgW21haWx0 bzpiZW5Abm9zdHJ1bS5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMjDml6UgNToz OA0KPiDmlLbku7bkuro6IERPTExZLCBNQVJUSU4gQw0KPiDmioTpgIE6IGRpbWVAaWV0Zi5vcmc7 IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBCRVJSWSwgTmlnZWwgKE5pZ2VsKTsgQmVzc2lzLCBUaGll cnJ5IChUaGllcnJ5KQ0KPiDkuLvpopg6IFJlOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBE ZWZhdWx0ICJJbXBsaWNpdCIgU2NvcGUNCj4gDQo+IEJ5ICJpbXBsaWNpdCIgc2NvcGUsIGFyZSB3 ZSByZWFsbHkgdGFsa2luZyBhYm91dCBhICJkZWZhdWx0IiBzY29wZT8gVGhhdCBpcywgYSBzY29w ZSBhc3N1bWVkIHRvIGJlIGFjdGl2ZSBpZiBubyBzY29wZSBpcyByZXBvcnRlZCwgYnV0IGlzIG92 ZXJyaWRkZW4gaWYgYW55IGV4cGxpY2l0IHNjb3BlIGlzIHJlcG9ydGVkPw0KPiANCj4gSWYgc28s IEkgZG9uJ3Qgb2JqZWN0IGluIHByaW5jaXBsZS4gQnV0IEkgdGhpbmsgdGhlIGNob2ljZSBvZiBh IGRlZmF1bHQgc2hvdWxkIGJlIHRoZSBzY29wZSB0aGF0IHdlIHRoaW5rIHdpbGwgYmUgdXNlZCB0 aGUgbW9zdCBvZnRlbi4gDQo+IA0KPiBZb3UgbWVudGlvbiBBcHBsaWNhdGlvbi1JZC4gVGhhdCBt YWtlcyBzZW5zZSBmb3IgYSBkZWZhdWx0IGlmIHlvdSBleHBlY3QgQXBwbGljYXRpb24tSWQgdG8g YWN0dWFsbHkgYmUgc2VsZWN0aXZlIG1vc3Qgb2YgdGhlIHRpbWUsIHRoYXQgaXMsIHlvdSBleHBl Y3Qgbm9kZXMgdG8gIHNlbmQgbG90cyBvZiByZXF1ZXN0cyB3aXRoIGRpZmZlcmVudCBBcHBsaWNh dGlvbi1JZHMgdG8gdGhlIHNhbWUgZGVzdGluYXRpb24uIFRoYXQncyBwcm9iYWJseSB0cnVlIGlm IHRoZSBkZXN0aW5hdGlvbiBpcyBhbiBhZ2VudCB0aGF0IHJvdXRlcyByZXF1ZXN0IGZvciBtb3Jl IHRoYW4gb25lIGFwcGxpY2F0aW9uLiBPVE9ILCBkbyB5b3UgdXN1YWxseSBzZWUgYSBjbGllbnQg c2VuZCByZXF1ZXN0cyBmb3IgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlvbiBvbiBhIHNpbmdsZSB0 cmFuc3BvcnQgbGF5ZXIgY29ubmVjdGlvbj8NCj4gDQo+IE15IGtuZWVqZXJrIHJlYWN0aW9uIGlz IHRvIHRoaW5rIHRoYXQgdGhlIG1vc3QgY29tbW9ubHkgdXNlZCBzY29wZSB3aWxsIGJlICJjb25u ZWN0aW9uIi4NCj4gDQo+IE9UT0gsIEFwcGxpY2F0aW9uLUlkIG9yIENvbm5lY3Rpb24gY2FuIGVh Y2ggYmUgaW5kaWNhdGVkIGJ5IGEgc2luZ2xlIEFWUC4gRG8gd2UgZ2FpbiBtdWNoIGluIGFsbG93 aW5nIGl0IHRvIGJlIGRlZmF1bHRlZD8gSkphY3F1ZXMgcHJldmlvdXNseSBtZW50aW9uZWQgIkRl c3RpbmF0aW9uIEhvc3QvZGVzdGluYXRpb24gcmVhbG0sIG9yaWdpbiBIb3N0L29yaWdpbiByZWFs bSwgZm9yIGEgZ2l2ZW4gQXBwbGljYXRpb24gSUQiLCB3aGljaCBpcyBhIGNvbXBvc2l0ZSB0aGF0 IHdvdWxkIHJlcXVpcmUgNC01IHNjb3BlIEFWUHMgdG8gZXhwcmVzcy4gSSBkb24ndCB0aGluayB0 aGF0IGNvbWJpbmF0aW9uIHdvdWxkIG5lY2Vzc2FyaWx5IG1ha2UgYSBnb29kIGRlZmF1bHQsIGJ1 dCBJIGNhbiBzZWUgb25lIG1pZ2h0IHdhbnQgdG8gYmUgYWJsZSB0byBleHByZXNzIGl0IChhbmQg bW9yZSBpbXBvcnRhbnRseSwgbmVnb3RpYXRlIHRoYXQgeW91IGNhbiBhY2NlcHQgdGhhdCBjb21i aW5hdGlvbiwgYnV0IG5vdCBvdGhlciBjb21iaW5hdGlvbnMgb2YgdGhlIHNhbWUgc2NvcGVzLikg V2UgY291bGQgYWx3YXlzIGFkZCBzb21lIG5ldyBzY29wZS10eXBlIHRoYXQgbWVhbnMgIlRoaXMg ZGVzdGluYXRpb24taG9zdCwgVGhpcyBhcHBsaWNhdGlvbi1JZCIsIGV0Yy4gKEknbSBub3Qgc3Vn Z2VzdGluZyB3ZSBkbyBzbyBub3csIGJ1dCBzaW5jZSB3ZSBpbnRlbmRlZCBzY29wZXMgdG8gYmUg ZXh0ZW5zaWJsZSwgd2UgY291bGQgYWx3YXlzIGFkZCB0aGF0IGRvd24gdGhlIHJvYWQgaWYgd2Ug ZmluZCB0aGUgbmVlZCB0byBkbyBzby4NCj4gDQo+IA0KPiBPbiBKdWwgMTksIDIwMTMsIGF0IDQ6 MTggUE0sICJET0xMWSwgTUFSVElOIEMiIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQo+IA0KPj4g QmVuL2FsbCwNCj4+IA0KPj4gSSBiZWxpZXZlIHRoZXJlIGNvdWxkIGJlIGFuICJpbXBsaWNpdCIg c2NvcGUgdGhhdCBpcyBjb21tb24gdG8gYWxsIHVzZSBjYXNlcyAoZS5nLCBBcHBsaWNhdGlvbi1J RCkuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IE1hcnRpbg0KPj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuIENhbXBiZWxsDQo+PiBTZW50 OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgNDo1NSBQTQ0KPj4gVG86IFRST1RUSU4sIEpFQU4tSkFD UVVFUyAoSkVBTi1KQUNRVUVTKQ0KPj4gQ2M6IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBkaW1lQGll dGYub3JnOyBCRVJSWSwgTmlnZWwgKE5pZ2VsKTsgQmVzc2lzLCBUaGllcnJ5IChUaGllcnJ5KQ0K Pj4gU3ViamVjdDogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxp Y2l0IiBTY29wZQ0KPj4gDQo+PiANCj4+IE9uIEp1bCAxOSwgMjAxMywgYXQgODowNyBBTSwgIlRS T1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKSIgPGplYW4tamFjcXVlcy50cm90dGlu QGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+PiANCj4+PiBIaSBhbGwNCj4+PiANCj4+PiBJ IGNvbWUgYmFjayBvbiBteSBtYWlsIEkgc2VudCB5b3UgbGFzdCBUdWVzZGF5IG9uIGFuIGltcGxp Y2l0IHNjb3BlIC4gQXMgSSBzYWlkLCBJIGFtIGNvbmNlcm5lZCB3aXRoIHRoZSBudW1iZXIgb2Yg c2NvcGVzIGFuZCB0aGVpciBjb21iaW5hdGlvbnMgaW4gdGhlIGRyYWZ0LXJvYWNoIHNvbHV0aW9u ICB3aGljaCBhZGRzIGNvbXBsZXhpdHksIGFuZCBmb3IgdGhpcyBzb2x1dGlvbiBJIHByb3Bvc2Vk IHRvIGNvbnNpZGVyIGFuIGltcGxpY2l0IHNjb3BlIHdoaWNoIGZvciBtZSBzaG91bGQgZml0IG1h bnkgY2FzZXMuIA0KPj4+IA0KPj4+IEhhbm5lcyBoYXMgYSBzaW1pbGFyIGNvbmNlcm4gYW5kIGlu IGhpcyBuZXcgc29sdXRpb24gZm9yIG92ZXJsb2FkIGhlIGZvY3VzZWQgb24gYSBtaW5pbWFsIG1l Y2hhbmlzbSB3aGVyZSB0aGVyZSBpcyAgbm8gbW9yZSBleHBsaWNpdCBzY29wZXMuIEJlaGluZCB0 aGlzIG1pbmltYWwgbWVjaGFuaXNtLCB0aGVyZSBpcyBhbiBpbXBsaWNpdCBzY29wZSB3aGljaCBJ IHRoaW5rIGlzIG5vdCBmYXIgZnJvbSBtaW5lLg0KPj4gDQo+PiBJJ20gbm90IHN1cmUgSSB1bmRl cnN0YW5kIHdoYXQgdGhlIGltcGxpY2l0IHNjb3BlIGlzIGluIEhhbm5lcydzIGRyYWZ0LiANCj4+ IA0KPj4+IA0KPj4+IEZyb20gdGhlc2UgaW5wdXRzLCBJIHRoaW5rIHRoZSBncm91cCBzaG91bGQg aW52ZXN0aWdhdGUgYSBiYXNpYyB2ZXJzaW9uIG9mIHRoZSBvdmVybG9hZCBjb250cm9sIG1lY2hh bmlzbSB3aGljaCBjb3VsZCBiZSBhbHNvIHBhcnQgb2YgdGhlIGRyYWZ0IHJvYWNoIHNvbHV0aW9u IGFuZCBzZWUgd2hpY2ggZXh0ZW5zaW9ucyBhcmUgbmVlZGVkLg0KPj4gDQo+PiBJIGNvbmN1ciB3 ZSBuZWVkIHRoZSBtb3N0IHNpbXBsZSBzb2x1dGlvbiB0aGF0IG1lZXRzIHRoZSByZXF1aXJlbWVu dHMuIEJ1dCBJIHRoaW5rIHRoYXQsIHdpdGhvdXQgYXQgbGVhc3Qgc29tZSBjb25jZXB0IG9mIHNj b3BlcywgaXQncyBnb2luZyB0byBiZSB2ZXJ5IGhhcmQgdG8gY29tZSB1cCB3aXRoIGEgbWVjaGFu aXNtIHRoYXQgZG9lc24ndCBkbyBtb3JlIGhhcm0gdGhhbiBnb29kLiBFaXRoZXIgaXQgd2lsbCBp bmNyZWFzZSB0aGUgaW1wYWN0IG9mIGFuIG92ZXJsb2FkIGNvbmRpdGlvbiBieSBmb3JjaW5nIHJl cXVlc3RzIHRvIGJlIHJlamVjdGVkIHVubmVjZXNzYXJpbHksIG9yIGl0IHdpbGwgY2F1c2UgY2xp ZW50cyBhbmQgcmVsYXlzIHRvIGF0dGVtcHQgdG8gc2VuZCByZXF1ZXN0cyB0byBhbHRlcm5hdGUg ZGVzdGluYXRpb25zLCB3aGljaCBhcmUgbGlrZWx5IGFsc28gb3ZlcmxvYWRlZC4NCj4+IA0KPj4+ IA0KPj4+IA0KPj4+IEJlc3QgcmVnYXJkcw0KPj4+IA0KPj4+IEpKYWNxdWVzDQo+Pj4gDQo+Pj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4gRGUgOiBUUk9UVElOLCBKRUFOLUpBQ1FV RVMgKEpFQU4tSkFDUVVFUykgDQo+Pj4gRW52b3nDqSA6IG1hcmRpIDE2IGp1aWxsZXQgMjAxMyAx MToxMg0KPj4+IMOAIDogZGltZUBpZXRmLm9yZw0KPj4+IENjIDogQkVSUlksIE5pZ2VsIChOaWdl bCk7IEJlc3NpcywgVGhpZXJyeSAoVGhpZXJyeSk7IERSQUdFLCBLZWl0aCAoS2VpdGgpDQo+Pj4g T2JqZXQgOiBSRTogW0RpbWVdIERpYW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGljaXQi IFNjb3BlDQo+Pj4gDQo+Pj4gSGkgQmVuLCBFcmljIGFuZCBhbGwNCj4+PiANCj4+PiANCj4+PiBB Ym91dCB0aGUgaW1wbGljaXQgc2NvcGUsIEkgYW0gdGhpbmtpbmcgdG8gdGhlIG9uZSB1c2VkIGZv ciBhbiBvdmVybG9hZCBpbmZvIHdoaWNoIHJlbGF0ZXMgdG8gdGhlIHRyYWZmaWMgdG8gd2hpY2gg dGhlIG1lc3NhZ2UgdHJhbnNwb3J0aW5nIHRoaXMgb3ZlcmxvYWQgaW5mbyBiZWxvbmdzLCBtZWFu aW5nIHRoZSB0cmFmZmljIGJldHdlZW4gYSBEZXN0aW5hdGlvbiBIb3N0L2Rlc3RpbmF0aW9uIHJl YWxtLCBvcmlnaW4gSG9zdC9vcmlnaW4gcmVhbG0sIGZvciBhIGdpdmVuIEFwcGxpY2F0aW9uIElE LiBUaGlzIHNjb3BlIGlzIGltcGxpY2l0bHkgZGVmaW5lZCBieSB0aGVzZSBBVlBzIG9mIHRoZSBt ZXNzYWdlIGFuZCBkb2VzIG5vdCByZXF1aXJlIGEgY29tYmluYXRpb24gb2YgU2NvcGUgQVZQcw0K Pj4+IA0KPj4+IEFub3RoZXIgcG9pbnQgaXMgb24gaG93IHRvIGxpbWl0IHRoZSBudW1iZXIgb2Yg c2NvcGVzIGFuZCB0aGVpciBjb21iaW5hdGlvbnMuIFN1Y2ggYSBudW1iZXIgb2YgcG9zc2liaWxp dGllcyBpbmNyZWFzZSB0aGUgY29tcGxleGl0eSBvZiB0aGUgb3ZlcmxvYWQgY29udHJvbCBtYW5h Z2VtZW50LCB3aGljaCBpbmNyZWFzZXMgdGhlIHJpc2tzLiBUaGUgaW1wbGljaXQgc2NvcGUgaXMg YW4gYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24gYXMgaXQgY2FuIGJlIHVzZWQgaW5zdGVhZCBvZiB0 aGUgb3RoZXIgc2NvcGVzIHN1Y2ggYXMgRGVzdGluYXRpb24gSG9zdCwgT3JpZ2luIEhvc3QsIGFw cGxpY2F0aW9uIElELCBjb25uZWN0aW9uLCBhbmQgdGhlaXIgY29tYmluYXRpb25zIGluIG1hbnkg Y2FzZXMuDQo+Pj4gDQo+Pj4gQmVzdCByZWdhcmRzDQo+Pj4gDQo+Pj4gSkphY3F1ZXMNCj4+PiAN Cj4+PiANCj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+PiBEZSA6IGRpbWUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBCZW4gQ2FtcGJlbGwNCj4+PiBFbnZvecOpIDogbHVuZGkgMTUganVpbGxldCAyMDEzIDAxOjA0 DQo+Pj4gw4AgOiBFcmljIE1jTXVycnkNCj4+PiBDYyA6IGRpbWVAaWV0Zi5vcmcNCj4+PiBPYmpl dCA6IFJlOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBEZWZhdWx0ICJJbXBsaWNpdCIgU2Nv cGUNCj4+PiANCj4+PiANCj4+PiBPbiBKdWwgMTQsIDIwMTMsIGF0IDM6NTkgUE0sIEVyaWMgTWNN dXJyeSA8ZW1jbXVycnlAY29tcHV0ZXIub3JnPiB3cm90ZToNCj4+PiANCj4+Pj4gDQo+Pj4+IE9u IEp1bCAxNCwgMjAxMywgYXQgMTM6MDEgLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4g d3JvdGU6DQo+Pj4+IA0KPj4+Pj4gT24gSnVsIDE0LCAyMDEzLCBhdCA5OjQxIEFNLCBFcmljIE1j TXVycnkgPGVtY211cnJ5QGNvbXB1dGVyLm9yZz4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiBIaSBN YXJ0aW4sDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGVjaG5pY2FsbHkgdGhhdCBzaG91bGQgYmUgcG9zc2li bGUuICBJIGhhdmUgc29tZSBjb25jZXJuIGFib3V0IG1peGluZyBpbXBsaWNpdCBhbmQgZXhwbGlj aXQgc2NvcGVzIHRob3VnaC4gIFRoYXQgY291bGQgYmUgY29uZnVzaW5nLiAgSSB3b3VsZCB0aGlu ayBpdCB3b24ndCBiZSB0aGF0IGhhcmQgdG8gcHV0IHRob3NlIHR3byBzY29wZXMgaW50byBjb250 cm9sIGluZm9ybWF0aW9uIHRoZXkgYXBwbHkgdG8uIA0KPj4+Pj4+IA0KPj4+Pj4+IFBlcmhhcHMg b3RoZXJzIGhhdmUgdGhvdWdodHMgb24gbWl4aW5nIGltcGxpY2l0IGFuZCBleHBsaWNpdCBzY29w ZXM/DQo+Pj4+PiANCj4+Pj4+IEkgdGhpbmsgdGhpcyBkZXBlbmRzIG9uIHdoYXQgd2UgbWVhbiBi eSBpbXBsaWNpdCBzY29wZXMuIElzIGFuIGltcGxpY2l0IHNjb3BlIGEgZGVmYXVsdCB0aGF0IGlz IHVzZWQgaWYgbm8gc2NvcGUgaW5kaWNhdG9ycyBhcmUgaW4gYW4gb3ZlcmxvYWQgcmVwb3J0PyBP ciBpcyBpdCBhIHNjb3BlIHRoYXQgaXMgYXNzdW1lZCB0byBiZSBpbiBhbGwgcmVwb3J0cyBldmVu IGlmIG5vdCBpbmRpY2F0ZWQ/IEkgdGhpbmsgdGhlIGZpcnN0IF9taWdodF8gbWFrZSBzZW5zZS4g VGhlIHNlY29uZCBydW5zIGFmb3VsIG9mIHlvdXIgY29uY2VybiBhYm91dCBtaXhpbmcgaW1wbGlj aXQgYW5kIGV4cGxpY2l0Lg0KPj4+Pj4gDQo+Pj4+PiBJbiBnZW5lcmFsLCB0aG91Z2gsIEkgbGVh biB0b3dhcmRzIHRoaW5raW5nIGV4cGxpY2l0IGlzIHVzdWFsbHkgYmV0dGVyLiBJIGNhbiBzZWUg c29tZSB1c2VzIGZvciBpbXBsaWNpdCwgZm9yIGV4YW1wbGUgaWYgYW4gSVAgYWRkcmVzcyBpcyBv YnNjdXJlZCBieSBhIE5BVCwgYSBub2RlIG1pZ2h0IG5vdCBiZSBhYmxlIHRvIGV4cGxpY2l0bHkg aW5kaWNhdGUgaXRzIElQIGFkZHJlc3MgdG8gYSBwZWVyLiBCdXQgdGhhdCB3b3VsZCBiZSBtb3Jl IG9mIGFuIGV4cGxpY2l0IHNjb3BlIGluZGljYXRpb24gd2l0aCBhbiBpbXBsaWNpdCB2YWx1ZS4g Rm9yIGV4YW1wbGUgYSBIb3N0IHNjb3BlIHdpdGggYSB2YWx1ZSBvZiAid2hhdGV2ZXIgSVAgYWRk cmVzcyB5b3UgcmVjZWl2ZWQgdGhpcyByZXF1ZXN0IGZyb20iDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+ IFRoZSAid2hhdGV2ZXIgSVAgeW91IHJlY2VpdmVkIHRoaXMgcmVxdWVzdCBmcm9tIiBjb25jZXB0 IGNvdWxkIGJlIHVzZWZ1bCBmb3Igc29tZSBvdGhlciBzY29wZXMgYWxzby4gIEZvciBleGFtcGxl LCB3aGF0ZXZlciBjb25uZWN0aW9uIHlvdSByZWNlaXZlZCB0aGlzIHJlcXVlc3Qgb24sIG9yIHdo YXRldmVyIGFwcGxpY2F0aW9uIHlvdSByZWNlaXZlZCB0aGlzIHJlcXVlc3Qgb24uDQo+Pj4gDQo+ Pj4gSSBkb24ndCB0aGluayB0aGVyZSdzIGFueSBvdGhlciB3YXkgdG8gZG8gImNvbm5lY3Rpb24i IHRvIG1lYW4gYW55dGhpbmcgYnV0ICJ0aGlzIGNvbm5lY3Rpb24iLiBJIGd1ZXNzIHdlIGNvdWxk IGV4cGxpY2l0bHkgbmFtZSBhIDUtdHVwbGUsIGJ1dCBJIHN1c3BlY3QgdGhhdCB3YXkgbGVhZHMg dG8gbWFkbmVzcy4gT1RPSCwgInRoaXMgYXBwbGljYXRpb24iIGNvdWxkIGp1c3QgYXMgZWFzaWx5 IGJlIG5hbWVkIGV4cGxpY2l0bHksIHNvIEknbSBub3Qgc3VyZSB0aGVyZSdzIGEgYmVuZWZpdCB0 aGVyZS4NCj4+PiANCj4+Pj4gSSB3b25kZXIgaWYgdGhhdCB3b3VsZCBzYXRpc2Z5IHRoZSB1c2Ug Y2FzZXMgdGhhdCBmb2xrcyBhcmUgdGhpbmtpbmcgb2Ygd2hlbiB0aGV5IGJyaW5nIHVwIGltcGxp Y2l0IHNjb3Blcz8NCj4+PiANCj4+PiBJIGRvbid0IGtub3cgdGhlIGFuc3dlciB0aGVyZS0tdGhh dCdzIHdoeSBJIGFza2VkIGEgc2ltaWxhciBxdWVzdGlvbiBpbiB0aGUgcHJldmlvdXMgZW1haWwg Oi0pDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiBEaU1FIG1haWxpbmcgbGlzdA0KPj4+IERpTUVAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IERpTUUgbWFpbGluZyBsaXN0DQo+Pj4g RGlNRUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZQ0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4+IERpTUVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiANCj4gDQoNCg== From emcmurry@computer.org Tue Jul 23 01:10: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 359C621E8099 for ; Tue, 23 Jul 2013 01:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+howyLqp3A4 for ; Tue, 23 Jul 2013 01:10:45 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 378E421E808E for ; Tue, 23 Jul 2013 01:09:47 -0700 (PDT) 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 1V1XfE-000Ahp-9a; Tue, 23 Jul 2013 08:09:44 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id D9FDCC18159; Tue, 23 Jul 2013 03:09:39 -0500 (CDT) 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: U2FsdGVkX1/O+H1iX/EH2Kl0Du4dasOedUbGRWs8GA0= 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 3TdQKR_Y_2j8; Tue, 23 Jul 2013 03:09:33 -0500 (CDT) Received: from [192.168.13.6] (unknown [192.168.13.6]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 81583C18136; Tue, 23 Jul 2013 03:09:30 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> Date: Tue, 23 Jul 2013 10:09:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <697371D4-069C-4ECA-B94F-EA67DCA775C9@computer.org> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> To: Shishufeng (Susan) X-Mailer: Apple Mail (2.1508) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 23 Jul 2013 08:10:55 -0000 Hi Susan, Your description of behavior leads me to think you mean default when you = are saying implicit. That is, when no scope is explicitly defined (and = only when no scope is explicitly defined), you want a default scope to = apply. =20 I agree with Ben that a default is probably okay. One way or another we = do need to define the behavior when no scope is specified explicitly. As to the question of what a default should be, I also agree with Ben = that analysis of the use cases would be beneficial here. For me, = connection makes the most sense, since peers are the elements that = generally care about overload information and cases with all the = topology exposed or with no agents will likely not be the norm (I think = that is where we may be seeing things differently). I am considering = primarily 3gpp deployments when making that statement. For your last statement, I'm a bit confused by your use of "mandated." = I read that along with the rest of the statement as saying there are, or = should be, some scopes which are mandatory to use. That is different = than mandatory to support. I don't think any of the proposals have any = mandatory to use scopes (nor should they). The sender of overload = information always chooses an appropriate scope to attach to its = information (which could be indicated using a default scope in the = protocol, but the sender still has to make a choice). Thanks, Eric On Jul 23, 2013, at 9:57 , Shishufeng (Susan) = wrote: > Hi Ben, >=20 > I'm not sure if "implicit" means "default", but should be very similar = to each other on this point. >=20 > In my understanding, "Connection" scope focus on transport connection = which is limited between two adjacent peers. While in 3GPP Diameter = applications, the important thing for overload control is to exchange = load/overload between client and server for which there might not be = direct transport connection.=20 >=20 > To make things simple and the mechanism defined in IETF more common, I = would propose to not have any scope mandated and leave it for = applications to decide if explicit scope(s) is(are) needed or an = implicit scope can be applied. >=20 > Best Regards, > Susan >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8823=E6=97=A5= 5:08 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Shishufeng (Susan) > =E6=8A=84=E9=80=81: DOLLY, MARTIN C; dime@ietf.org; DRAGE, Keith = (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) > =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >=20 > Hi Susan, >=20 > When you say "implicit" scope, do you mean a default? (that is, one = that applies if no scope is explicitly included)? I'm not opposed to = having such a comment, but I think we need to look more closely at how = Diameter servers tend to actually be deployed, and where we save = complexity. Realm + Application + Destination-Host + Origin-Host is a = fairly complex scope. But the complexity is not in how you express it on = the wire--that's pretty easy. It's also not how you interpret the = scope--that's a one time action per overload report. The really hard = part is the decision function that the reacting node applies to every = single request to determine if the scope applies to it. And that's true = whether the scope is implicitly or explicitly included in an overload = report. >=20 > It seems to me that if we define a default scope, it should be both = commonly used and simple. The one that you and JJ have proposed may be = common, but it's not simple. I think this needs more analysis, but so = far I think that "Connection" is the strongest candidate for being both = common and simple. >=20 >=20 >=20 > On Jul 21, 2013, at 9:53 PM, Shishufeng (Susan) = wrote: >=20 >> Hello all, >>=20 >> I would support to have an implicit scope limited to what's contained = in the message itself, i.e. as mentioned by JJ, specific application, = specific host, and specific destination. Or you can call it as a = combination of "Destination Host/destination realm, origin Host/origin = realm, for a given Application ID". =46rom my point of view, a very = simply use case of overload control for 3GPP Diameter applications is = that the server sends its load/overload information to the client, the = client decides to throttle or not messages related to the corresponding = application to the server. E.g. for 3GPP S6a, after update location = procedure, the MME would store one specific HSS identity for each UE = attached for easy routing of subsequent messages. To this MME, it only = cares if this HSS is overloaded. This does not prevent to deploy = Diameter Agents for load balancing, which can redirect the requests to = other non-overloading servers or change the level of the overload = situation of the server. But to the client, it can always see one = specific server at a specific time. >>=20 >> Best Regards, >> Susan >>=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8820=E6=97=A5= 5:38 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: DOLLY, MARTIN C >> =E6=8A=84=E9=80=81: dime@ietf.org; DRAGE, Keith (Keith); BERRY, Nigel = (Nigel); Bessis, Thierry (Thierry) >> =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >>=20 >> By "implicit" scope, are we really talking about a "default" scope? = That is, a scope assumed to be active if no scope is reported, but is = overridden if any explicit scope is reported? >>=20 >> If so, I don't object in principle. But I think the choice of a = default should be the scope that we think will be used the most often.=20= >>=20 >> You mention Application-Id. That makes sense for a default if you = expect Application-Id to actually be selective most of the time, that = is, you expect nodes to send lots of requests with different = Application-Ids to the same destination. That's probably true if the = destination is an agent that routes request for more than one = application. OTOH, do you usually see a client send requests for more = than one application on a single transport layer connection? >>=20 >> My kneejerk reaction is to think that the most commonly used scope = will be "connection". >>=20 >> OTOH, Application-Id or Connection can each be indicated by a single = AVP. Do we gain much in allowing it to be defaulted? JJacques previously = mentioned "Destination Host/destination realm, origin Host/origin realm, = for a given Application ID", which is a composite that would require 4-5 = scope AVPs to express. I don't think that combination would necessarily = make a good default, but I can see one might want to be able to express = it (and more importantly, negotiate that you can accept that = combination, but not other combinations of the same scopes.) We could = always add some new scope-type that means "This destination-host, This = application-Id", etc. (I'm not suggesting we do so now, but since we = intended scopes to be extensible, we could always add that down the road = if we find the need to do so. >>=20 >>=20 >> On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" = wrote: >>=20 >>> Ben/all, >>>=20 >>> I believe there could be an "implicit" scope that is common to all = use cases (e.g, Application-ID). >>>=20 >>> Regards, >>>=20 >>> Martin >>>=20 >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Ben Campbell >>> Sent: Friday, July 19, 2013 4:55 PM >>> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >>> Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); = Bessis, Thierry (Thierry) >>> Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>=20 >>>=20 >>> On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>>=20 >>>> Hi all >>>>=20 >>>> I come back on my mail I sent you last Tuesday on an implicit scope = . As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >>>>=20 >>>> Hannes has a similar concern and in his new solution for overload = he focused on a minimal mechanism where there is no more explicit = scopes. Behind this minimal mechanism, there is an implicit scope which = I think is not far from mine. >>>=20 >>> I'm not sure I understand what the implicit scope is in Hannes's = draft.=20 >>>=20 >>>>=20 >>>> =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. >>>=20 >>> I concur we need the most simple solution that meets the = requirements. But I think that, without at least some concept of scopes, = it's going to be very hard to come up with a mechanism that doesn't do = more harm than good. Either it will increase the impact of an overload = condition by forcing requests to be rejected unnecessarily, or it will = cause clients and relays to attempt to send requests to alternate = destinations, which are likely also overloaded. >>>=20 >>>>=20 >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>>=20 >>>> -----Message d'origine----- >>>> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>>> Envoy=C3=A9 : mardi 16 juillet 2013 11:12 >>>> =C3=80 : dime@ietf.org >>>> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) >>>> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >>>>=20 >>>> Hi Ben, Eric and all >>>>=20 >>>>=20 >>>> About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >>>>=20 >>>> Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la = part de Ben Campbell >>>> Envoy=C3=A9 : lundi 15 juillet 2013 01:04 >>>> =C3=80 : Eric McMurry >>>> Cc : dime@ietf.org >>>> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>>=20 >>>>=20 >>>> On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >>>>=20 >>>>>=20 >>>>> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>>>>=20 >>>>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>>>>=20 >>>>>>> Hi Martin, >>>>>>>=20 >>>>>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>>>>=20 >>>>>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>>>>=20 >>>>>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>>>>=20 >>>>>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>>>>=20 >>>>>=20 >>>>> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >>>>=20 >>>> I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >>>>=20 >>>>> I wonder if that would satisfy the use cases that folks are = thinking of when they bring up implicit scopes? >>>>=20 >>>> I don't know the answer there--that's why I asked a similar = question in the previous email :-) >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Jul 23 07:11:43 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 137F611E822A for ; Tue, 23 Jul 2013 07:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7F-yY4msiNo for ; Tue, 23 Jul 2013 07:11:41 -0700 (PDT) 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 6436211E81DB for ; Tue, 23 Jul 2013 07:11:41 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6NEBT6d092665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jul 2013 09:11:29 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> Date: Tue, 23 Jul 2013 09:11:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> To: Shishufeng (Susan) X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 23 Jul 2013 14:11:43 -0000 Hi Susan, If there is no direct connection, then we are talking about the = non-adjacent overload control case. That's not (yet) covered at all in = the original two proposals. It's not clear to me if Hannes's proposal is = intended to do so. Have you (and others) had a chance to read the non-adjacent section in = draft-campbell-dime-overload-issues-01? The group has had some = discussion about the scopes analysis in that draft, but no one has = commented much on the non-adjacent overload control analysis. I am reasonably okay with saying no specific scope is required by the = base mechanism, as long as we (continue to) let nodes declare what they = can receive. The working group should discuss whether we might want at = least one mandatory-to-implement scope to try to avoid "islands" of = interoperability. I won't be too unhappy whichever way we go on that, as = long as we understand the implications. Thanks! Ben. =20 On Jul 23, 2013, at 2:57 AM, Shishufeng (Susan) = wrote: > Hi Ben, >=20 > I'm not sure if "implicit" means "default", but should be very similar = to each other on this point. >=20 > In my understanding, "Connection" scope focus on transport connection = which is limited between two adjacent peers. While in 3GPP Diameter = applications, the important thing for overload control is to exchange = load/overload between client and server for which there might not be = direct transport connection.=20 >=20 > To make things simple and the mechanism defined in IETF more common, I = would propose to not have any scope mandated and leave it for = applications to decide if explicit scope(s) is(are) needed or an = implicit scope can be applied. >=20 > Best Regards, > Susan >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8823=E6=97=A5= 5:08 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Shishufeng (Susan) > =E6=8A=84=E9=80=81: DOLLY, MARTIN C; dime@ietf.org; DRAGE, Keith = (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) > =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >=20 > Hi Susan, >=20 > When you say "implicit" scope, do you mean a default? (that is, one = that applies if no scope is explicitly included)? I'm not opposed to = having such a comment, but I think we need to look more closely at how = Diameter servers tend to actually be deployed, and where we save = complexity. Realm + Application + Destination-Host + Origin-Host is a = fairly complex scope. But the complexity is not in how you express it on = the wire--that's pretty easy. It's also not how you interpret the = scope--that's a one time action per overload report. The really hard = part is the decision function that the reacting node applies to every = single request to determine if the scope applies to it. And that's true = whether the scope is implicitly or explicitly included in an overload = report. >=20 > It seems to me that if we define a default scope, it should be both = commonly used and simple. The one that you and JJ have proposed may be = common, but it's not simple. I think this needs more analysis, but so = far I think that "Connection" is the strongest candidate for being both = common and simple. >=20 >=20 >=20 > On Jul 21, 2013, at 9:53 PM, Shishufeng (Susan) = wrote: >=20 >> Hello all, >>=20 >> I would support to have an implicit scope limited to what's contained = in the message itself, i.e. as mentioned by JJ, specific application, = specific host, and specific destination. Or you can call it as a = combination of "Destination Host/destination realm, origin Host/origin = realm, for a given Application ID". =46rom my point of view, a very = simply use case of overload control for 3GPP Diameter applications is = that the server sends its load/overload information to the client, the = client decides to throttle or not messages related to the corresponding = application to the server. E.g. for 3GPP S6a, after update location = procedure, the MME would store one specific HSS identity for each UE = attached for easy routing of subsequent messages. To this MME, it only = cares if this HSS is overloaded. This does not prevent to deploy = Diameter Agents for load balancing, which can redirect the requests to = other non-overloading servers or change the level of the overload = situation of the server. But to the client, it can always see one = specific server at a specific time. >>=20 >> Best Regards, >> Susan >>=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8820=E6=97=A5= 5:38 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: DOLLY, MARTIN C >> =E6=8A=84=E9=80=81: dime@ietf.org; DRAGE, Keith (Keith); BERRY, Nigel = (Nigel); Bessis, Thierry (Thierry) >> =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >>=20 >> By "implicit" scope, are we really talking about a "default" scope? = That is, a scope assumed to be active if no scope is reported, but is = overridden if any explicit scope is reported? >>=20 >> If so, I don't object in principle. But I think the choice of a = default should be the scope that we think will be used the most often.=20= >>=20 >> You mention Application-Id. That makes sense for a default if you = expect Application-Id to actually be selective most of the time, that = is, you expect nodes to send lots of requests with different = Application-Ids to the same destination. That's probably true if the = destination is an agent that routes request for more than one = application. OTOH, do you usually see a client send requests for more = than one application on a single transport layer connection? >>=20 >> My kneejerk reaction is to think that the most commonly used scope = will be "connection". >>=20 >> OTOH, Application-Id or Connection can each be indicated by a single = AVP. Do we gain much in allowing it to be defaulted? JJacques previously = mentioned "Destination Host/destination realm, origin Host/origin realm, = for a given Application ID", which is a composite that would require 4-5 = scope AVPs to express. I don't think that combination would necessarily = make a good default, but I can see one might want to be able to express = it (and more importantly, negotiate that you can accept that = combination, but not other combinations of the same scopes.) We could = always add some new scope-type that means "This destination-host, This = application-Id", etc. (I'm not suggesting we do so now, but since we = intended scopes to be extensible, we could always add that down the road = if we find the need to do so. >>=20 >>=20 >> On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" = wrote: >>=20 >>> Ben/all, >>>=20 >>> I believe there could be an "implicit" scope that is common to all = use cases (e.g, Application-ID). >>>=20 >>> Regards, >>>=20 >>> Martin >>>=20 >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Ben Campbell >>> Sent: Friday, July 19, 2013 4:55 PM >>> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >>> Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); = Bessis, Thierry (Thierry) >>> Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>=20 >>>=20 >>> On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>>=20 >>>> Hi all >>>>=20 >>>> I come back on my mail I sent you last Tuesday on an implicit scope = . As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >>>>=20 >>>> Hannes has a similar concern and in his new solution for overload = he focused on a minimal mechanism where there is no more explicit = scopes. Behind this minimal mechanism, there is an implicit scope which = I think is not far from mine. >>>=20 >>> I'm not sure I understand what the implicit scope is in Hannes's = draft.=20 >>>=20 >>>>=20 >>>> =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. >>>=20 >>> I concur we need the most simple solution that meets the = requirements. But I think that, without at least some concept of scopes, = it's going to be very hard to come up with a mechanism that doesn't do = more harm than good. Either it will increase the impact of an overload = condition by forcing requests to be rejected unnecessarily, or it will = cause clients and relays to attempt to send requests to alternate = destinations, which are likely also overloaded. >>>=20 >>>>=20 >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>>=20 >>>> -----Message d'origine----- >>>> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>>> Envoy=C3=A9 : mardi 16 juillet 2013 11:12 >>>> =C3=80 : dime@ietf.org >>>> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) >>>> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >>>>=20 >>>> Hi Ben, Eric and all >>>>=20 >>>>=20 >>>> About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >>>>=20 >>>> Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la = part de Ben Campbell >>>> Envoy=C3=A9 : lundi 15 juillet 2013 01:04 >>>> =C3=80 : Eric McMurry >>>> Cc : dime@ietf.org >>>> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>>=20 >>>>=20 >>>> On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >>>>=20 >>>>>=20 >>>>> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>>>>=20 >>>>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>>>>=20 >>>>>>> Hi Martin, >>>>>>>=20 >>>>>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>>>>=20 >>>>>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>>>>=20 >>>>>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>>>>=20 >>>>>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>>>>=20 >>>>>=20 >>>>> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >>>>=20 >>>> I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >>>>=20 >>>>> I wonder if that would satisfy the use cases that folks are = thinking of when they bring up implicit scopes? >>>>=20 >>>> I don't know the answer there--that's why I asked a similar = question in the previous email :-) >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >=20 From ben@nostrum.com Tue Jul 23 07:26: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 7F86A11E8153 for ; Tue, 23 Jul 2013 07:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryVYanBQ10+D for ; Tue, 23 Jul 2013 07:26:05 -0700 (PDT) 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 E83FE21F9BA4 for ; Tue, 23 Jul 2013 07:26:04 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6NEPLAi094253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jul 2013 09:25:21 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> Date: Tue, 23 Jul 2013 09:25:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> To: Shishufeng (Susan) X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 23 Jul 2013 14:26:07 -0000 Oops, left out a comment--see inline: On Jul 23, 2013, at 9:11 AM, Ben Campbell wrote: > Hi Susan, >=20 > If there is no direct connection, then we are talking about the = non-adjacent overload control case. That's not (yet) covered at all in = the original two proposals. It's not clear to me if Hannes's proposal is = intended to do so. >=20 > Have you (and others) had a chance to read the non-adjacent section in = draft-campbell-dime-overload-issues-01? The group has had some = discussion about the scopes analysis in that draft, but no one has = commented much on the non-adjacent overload control analysis. In particular, I do think any "default" scopes would be different for = non-adjacent than adjacent overload control. "Connection" is useless for = non-adjacent, but may be the most useful for adjacent. We may need to = rule out the Peer (or Host) scope and the Connection scope entirely for = non-adjacent use. I still have concerns about using a combined scope for the default, = though. I'd rather pick something simple to act on, i.e. not requiring = the reacting node to luck at several aspects of a request to determine = if it matches the scope. Essentially, I'm concerned about _defaulting_ = to requiring a boolean expression check on each and every request. >=20 > I am reasonably okay with saying no specific scope is required by the = base mechanism, as long as we (continue to) let nodes declare what they = can receive. The working group should discuss whether we might want at = least one mandatory-to-implement scope to try to avoid "islands" of = interoperability. I won't be too unhappy whichever way we go on that, as = long as we understand the implications. >=20 > Thanks! >=20 > Ben. >=20 >=20 > On Jul 23, 2013, at 2:57 AM, Shishufeng (Susan) = wrote: >=20 >> Hi Ben, >>=20 >> I'm not sure if "implicit" means "default", but should be very = similar to each other on this point. >>=20 >> In my understanding, "Connection" scope focus on transport connection = which is limited between two adjacent peers. While in 3GPP Diameter = applications, the important thing for overload control is to exchange = load/overload between client and server for which there might not be = direct transport connection.=20 >>=20 >> To make things simple and the mechanism defined in IETF more common, = I would propose to not have any scope mandated and leave it for = applications to decide if explicit scope(s) is(are) needed or an = implicit scope can be applied. >>=20 >> Best Regards, >> Susan >>=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8823=E6=97=A5= 5:08 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Shishufeng (Susan) >> =E6=8A=84=E9=80=81: DOLLY, MARTIN C; dime@ietf.org; DRAGE, Keith = (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) >> =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >>=20 >> Hi Susan, >>=20 >> When you say "implicit" scope, do you mean a default? (that is, one = that applies if no scope is explicitly included)? I'm not opposed to = having such a comment, but I think we need to look more closely at how = Diameter servers tend to actually be deployed, and where we save = complexity. Realm + Application + Destination-Host + Origin-Host is a = fairly complex scope. But the complexity is not in how you express it on = the wire--that's pretty easy. It's also not how you interpret the = scope--that's a one time action per overload report. The really hard = part is the decision function that the reacting node applies to every = single request to determine if the scope applies to it. And that's true = whether the scope is implicitly or explicitly included in an overload = report. >>=20 >> It seems to me that if we define a default scope, it should be both = commonly used and simple. The one that you and JJ have proposed may be = common, but it's not simple. I think this needs more analysis, but so = far I think that "Connection" is the strongest candidate for being both = common and simple. >>=20 >>=20 >>=20 >> On Jul 21, 2013, at 9:53 PM, Shishufeng (Susan) = wrote: >>=20 >>> Hello all, >>>=20 >>> I would support to have an implicit scope limited to what's = contained in the message itself, i.e. as mentioned by JJ, specific = application, specific host, and specific destination. Or you can call it = as a combination of "Destination Host/destination realm, origin = Host/origin realm, for a given Application ID". =46rom my point of view, = a very simply use case of overload control for 3GPP Diameter = applications is that the server sends its load/overload information to = the client, the client decides to throttle or not messages related to = the corresponding application to the server. E.g. for 3GPP S6a, after = update location procedure, the MME would store one specific HSS identity = for each UE attached for easy routing of subsequent messages. To this = MME, it only cares if this HSS is overloaded. This does not prevent to = deploy Diameter Agents for load balancing, which can redirect the = requests to other non-overloading servers or change the level of the = overload situation of the server. But to the client, it can always see = one specific server at a specific time. >>>=20 >>> Best Regards, >>> Susan >>>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20= >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8820=E6=97=A5= 5:38 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: DOLLY, MARTIN C >>> =E6=8A=84=E9=80=81: dime@ietf.org; DRAGE, Keith (Keith); BERRY, = Nigel (Nigel); Bessis, Thierry (Thierry) >>> =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default = "Implicit" Scope >>>=20 >>> By "implicit" scope, are we really talking about a "default" scope? = That is, a scope assumed to be active if no scope is reported, but is = overridden if any explicit scope is reported? >>>=20 >>> If so, I don't object in principle. But I think the choice of a = default should be the scope that we think will be used the most often.=20= >>>=20 >>> You mention Application-Id. That makes sense for a default if you = expect Application-Id to actually be selective most of the time, that = is, you expect nodes to send lots of requests with different = Application-Ids to the same destination. That's probably true if the = destination is an agent that routes request for more than one = application. OTOH, do you usually see a client send requests for more = than one application on a single transport layer connection? >>>=20 >>> My kneejerk reaction is to think that the most commonly used scope = will be "connection". >>>=20 >>> OTOH, Application-Id or Connection can each be indicated by a single = AVP. Do we gain much in allowing it to be defaulted? JJacques previously = mentioned "Destination Host/destination realm, origin Host/origin realm, = for a given Application ID", which is a composite that would require 4-5 = scope AVPs to express. I don't think that combination would necessarily = make a good default, but I can see one might want to be able to express = it (and more importantly, negotiate that you can accept that = combination, but not other combinations of the same scopes.) We could = always add some new scope-type that means "This destination-host, This = application-Id", etc. (I'm not suggesting we do so now, but since we = intended scopes to be extensible, we could always add that down the road = if we find the need to do so. >>>=20 >>>=20 >>> On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" = wrote: >>>=20 >>>> Ben/all, >>>>=20 >>>> I believe there could be an "implicit" scope that is common to all = use cases (e.g, Application-ID). >>>>=20 >>>> Regards, >>>>=20 >>>> Martin >>>>=20 >>>> -----Original Message----- >>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = Behalf Of Ben Campbell >>>> Sent: Friday, July 19, 2013 4:55 PM >>>> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >>>> Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); = Bessis, Thierry (Thierry) >>>> Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>>=20 >>>>=20 >>>> On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>>>=20 >>>>> Hi all >>>>>=20 >>>>> I come back on my mail I sent you last Tuesday on an implicit = scope . As I said, I am concerned with the number of scopes and their = combinations in the draft-roach solution which adds complexity, and for = this solution I proposed to consider an implicit scope which for me = should fit many cases.=20 >>>>>=20 >>>>> Hannes has a similar concern and in his new solution for overload = he focused on a minimal mechanism where there is no more explicit = scopes. Behind this minimal mechanism, there is an implicit scope which = I think is not far from mine. >>>>=20 >>>> I'm not sure I understand what the implicit scope is in Hannes's = draft.=20 >>>>=20 >>>>>=20 >>>>> =46rom these inputs, I think the group should investigate a basic = version of the overload control mechanism which could be also part of = the draft roach solution and see which extensions are needed. >>>>=20 >>>> I concur we need the most simple solution that meets the = requirements. But I think that, without at least some concept of scopes, = it's going to be very hard to come up with a mechanism that doesn't do = more harm than good. Either it will increase the impact of an overload = condition by forcing requests to be rejected unnecessarily, or it will = cause clients and relays to attempt to send requests to alternate = destinations, which are likely also overloaded. >>>>=20 >>>>>=20 >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> JJacques >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>>>> Envoy=C3=A9 : mardi 16 juillet 2013 11:12 >>>>> =C3=80 : dime@ietf.org >>>>> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith = (Keith) >>>>> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope >>>>>=20 >>>>> Hi Ben, Eric and all >>>>>=20 >>>>>=20 >>>>> About the implicit scope, I am thinking to the one used for an = overload info which relates to the traffic to which the message = transporting this overload info belongs, meaning the traffic between a = Destination Host/destination realm, origin Host/origin realm, for a = given Application ID. This scope is implicitly defined by these AVPs of = the message and does not require a combination of Scope AVPs >>>>>=20 >>>>> Another point is on how to limit the number of scopes and their = combinations. Such a number of possibilities increase the complexity of = the overload control management, which increases the risks. The implicit = scope is an answer to this question as it can be used instead of the = other scopes such as Destination Host, Origin Host, application ID, = connection, and their combinations in many cases. >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> JJacques >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la = part de Ben Campbell >>>>> Envoy=C3=A9 : lundi 15 juillet 2013 01:04 >>>>> =C3=80 : Eric McMurry >>>>> Cc : dime@ietf.org >>>>> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >>>>>=20 >>>>>=20 >>>>> On Jul 14, 2013, at 3:59 PM, Eric McMurry = wrote: >>>>>=20 >>>>>>=20 >>>>>> On Jul 14, 2013, at 13:01 , Ben Campbell wrote: >>>>>>=20 >>>>>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry = wrote: >>>>>>>=20 >>>>>>>> Hi Martin, >>>>>>>>=20 >>>>>>>> Technically that should be possible. I have some concern about = mixing implicit and explicit scopes though. That could be confusing. I = would think it won't be that hard to put those two scopes into control = information they apply to.=20 >>>>>>>>=20 >>>>>>>> Perhaps others have thoughts on mixing implicit and explicit = scopes? >>>>>>>=20 >>>>>>> I think this depends on what we mean by implicit scopes. Is an = implicit scope a default that is used if no scope indicators are in an = overload report? Or is it a scope that is assumed to be in all reports = even if not indicated? I think the first _might_ make sense. The second = runs afoul of your concern about mixing implicit and explicit. >>>>>>>=20 >>>>>>> In general, though, I lean towards thinking explicit is usually = better. I can see some uses for implicit, for example if an IP address = is obscured by a NAT, a node might not be able to explicitly indicate = its IP address to a peer. But that would be more of an explicit scope = indication with an implicit value. For example a Host scope with a value = of "whatever IP address you received this request from" >>>>>>>=20 >>>>>>=20 >>>>>> The "whatever IP you received this request from" concept could be = useful for some other scopes also. For example, whatever connection you = received this request on, or whatever application you received this = request on. >>>>>=20 >>>>> I don't think there's any other way to do "connection" to mean = anything but "this connection". I guess we could explicitly name a = 5-tuple, but I suspect that way leads to madness. OTOH, "this = application" could just as easily be named explicitly, so I'm not sure = there's a benefit there. >>>>>=20 >>>>>> I wonder if that would satisfy the use cases that folks are = thinking of when they bring up implicit scopes? >>>>>=20 >>>>> I don't know the answer there--that's why I asked a similar = question in the previous email :-) >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>=20 >=20 From ben@nostrum.com Tue Jul 23 07:45: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 DCBC621E8092 for ; Tue, 23 Jul 2013 07:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX1WXBakuRbN for ; Tue, 23 Jul 2013 07:45:39 -0700 (PDT) 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 D358A21E808A for ; Tue, 23 Jul 2013 07:45:38 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6NEjLux096405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jul 2013 09:45:21 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <697371D4-069C-4ECA-B94F-EA67DCA775C9@computer.org> Date: Tue, 23 Jul 2013 09:45:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8560B1D9-8DE9-4187-B805-C9E488D358D2@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <697371D4-069C-4ECA-B94F-EA67DCA775C9@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "Shishufeng \(Susan\)" , "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 23 Jul 2013 14:45:40 -0000 On Jul 23, 2013, at 3:09 AM, Eric McMurry wrote: > For your last statement, I'm a bit confused by your use of "mandated." = I read that along with the rest of the statement as saying there are, = or should be, some scopes which are mandatory to use. That is different = than mandatory to support. I don't think any of the proposals have any = mandatory to use scopes (nor should they). The sender of overload = information always chooses an appropriate scope to attach to its = information (which could be indicated using a default scope in the = protocol, but the sender still has to make a choice). It might be better to think of this as "mandatory to send" vs " = mandatory to accept". "Mandatory to support" may also be of interest, = but if entire sections of the deployment space turn off a feature by = configuration, one might as well consider it unsupported. From srdonovan@usdonovans.com Tue Jul 23 14:25: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 06B9C11E82F4 for ; Tue, 23 Jul 2013 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCtCDG7gfoLS for ; Tue, 23 Jul 2013 14:25:28 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id C21C211E8398 for ; Tue, 23 Jul 2013 14:24:46 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49682 helo=[192.168.1.146]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V1k4O-0002Aa-Q2; Tue, 23 Jul 2013 14:24:39 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Steve Donovan In-Reply-To: <8560B1D9-8DE9-4187-B805-C9E488D358D2@nostrum.com> Date: Tue, 23 Jul 2013 16:24:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <697371D4-069C-4ECA-B94F-EA67DCA775C9@computer.org> <8560B1D9-8DE9-4187-B805-C9E488D358D2@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan+usdonovans.com/only user confirmed/virtual account not confirmed Cc: "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "Shishufeng \(Susan\)" , "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 23 Jul 2013 21:25:33 -0000 Ben, It seems prudent to have at least one "mandatory to support" scope. It also seems to me that the most logical scope for this would be host. = It seems unlikely that there would be different overload state sent on = individual connections from a peer. It is also most likely to be the = case that all of the applications handled by the host will be in the = same overload state. =20 Clearly some implementations might allocate resources on a per = application basis and, as such, support overload detection on a appl-id = scope. The more likely implementation is to have shared resources that = experience the same overload events. Steve =20 On Jul 23, 2013, at 9:45 AM, Ben Campbell wrote: >=20 > On Jul 23, 2013, at 3:09 AM, Eric McMurry = wrote: >=20 >> For your last statement, I'm a bit confused by your use of = "mandated." I read that along with the rest of the statement as saying = there are, or should be, some scopes which are mandatory to use. That = is different than mandatory to support. I don't think any of the = proposals have any mandatory to use scopes (nor should they). The = sender of overload information always chooses an appropriate scope to = attach to its information (which could be indicated using a default = scope in the protocol, but the sender still has to make a choice). >=20 > It might be better to think of this as "mandatory to send" vs " = mandatory to accept". "Mandatory to support" may also be of interest, = but if entire sections of the deployment space turn off a feature by = configuration, one might as well consider it unsupported. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From bclaise@cisco.com Tue Jul 23 15:47:43 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 CD46E11E8166 for ; Tue, 23 Jul 2013 15:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ql0p3MbY4TC for ; Tue, 23 Jul 2013 15:47:39 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB511E8150 for ; Tue, 23 Jul 2013 15:47:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6NMlaK8017744 for ; Wed, 24 Jul 2013 00:47:36 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6NMlFgD021402 for ; Wed, 24 Jul 2013 00:47:25 +0200 (CEST) Message-ID: <51EF07E5.7070300@cisco.com> Date: Wed, 24 Jul 2013 00:47:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dime mailing list References: <51EE7BBE.1050804@cisco.com> In-Reply-To: <51EE7BBE.1050804@cisco.com> X-Forwarded-Message-Id: <51EE7BBE.1050804@cisco.com> Content-Type: multipart/alternative; boundary="------------030001030705010903080608" Subject: [Dime] AD review of draft-ietf-dime-realm-based-redirect 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, 23 Jul 2013 22:47:44 -0000 This is a multi-part message in MIME format. --------------030001030705010903080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Here is my AD review. If some points have been discussed on the mailing list, don't hesitate to let me know. 1. The following sentence contains twice "but instead" The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent, but instead must be performed by a redirect agent as defined in [RFC6733 ], but instead by an application-aware Diameter node (Diameter server or proxy). Don't you mean? The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent [RFC6733 ], but instead by an application-aware Diameter node (Diameter server or proxy). 2. Because realm-based redirection is not part of the Diameter base protocol [RFC6733 ], support of realm-based redirection_by a Redirect agent_ MUST be specified as part of functionality supported by a Diameter application. This contradicts the following sentence The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a_redirect agent_ [RFC6733 ], but instead by an application-aware Diameter node (Diameter server or proxy). Do I understand correctly that the justification is that, citing RFC 6733, Redirect Agents can't inspect the application. "Diameter relays and redirect agents are transparent to the Diameter applications, but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications." I could understand all this if "by a Redirect Agent" would be removed in the first paragraph. OLD: Because realm-based redirection is not part of the Diameter base protocol [RFC6733 ], support of realm-based redirection by a Redirect agent MUST be specified as part of functionality supported by a Diameter application. NEW: Because realm-based redirection is not part of the Diameter base protocol [RFC6733 ], support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. But then, if it doesn't apply to a Redirect Agent, then why do we have this paragraph However, despite the change in executing role, the behaviour itself is a slight modification of the behaviour of a redirect agent as described inSection 2.8.3 of [RFC6733] . 3. An application can specify that realm-based redirection operates only on the initial message of a session, or on any message of a session. "only the initial message" or "on any message of a session" = "on any message of a session", right? Remove "only", that would make sense with the next sentence in the paragraph. Same remark for the first paragraph in 3.2.1 4. I thought about this use case: "consider the case where an operator has offered a specific service but no longer wishes to do so. The operator has arranged for an alternative domain to provide the service." Don't we need "Redirect-Max-Cache-Time" = "forever"? Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is not present? I could not find a definitive answer in the draft or in RFC 6733 5. If the redirected request contained a Destination-Host AVP, that AVP is ignored by the redirecting server. Pay attention that you update RFC 6733 Proposal If the redirected request contains a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, that Destination-Host AVP MUST be ignored by the redirecting server. Or When a directed request contains a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP content MUST be ignored by the redirecting server. 6. A proxy conforming to this specification that receives an answer message with the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the original request to a server in a realm identified by a Redirect- Realm AVP instance in the answer message, or MAY simply forward the message toward the client. It MUST do one of the two things, I guess. Otherwise, doing nothing is also a valid option according to the text. Please mention it. 7. Section 3.2.2 And what if all point of the procedure fail, for all realms, what should happen? DIAMETER_REDIRECT_INDICATION to the client? Editorial - Redirect agent versus redirect agent - Redirecting Server is a new term AFAICT, and is not really defined (even if we can guess). Is this intentional? Regards, Benoit --------------030001030705010903080608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Dear authors,

Here is my AD review.
If some points have been discussed on the mailing list, don't hesitate to let me know.


1.
The following sentence contains twice "but instead"

   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent, but
   instead must be performed by a redirect agent as defined in
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy). 

Don't you mean?

   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent 
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy). 


2.

   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection by a Redirect
   agent MUST be specified as part of functionality supported by a
   Diameter application.
   
This contradicts the following sentence
  
   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent 
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy).

Do I understand correctly that the justification is that, citing RFC 6733, Redirect Agents can't inspect the application.
   "Diameter relays and redirect agents are transparent to the Diameter
   applications, but they MUST support the Diameter base protocol, which
   includes accounting, and all Diameter applications." 

I could understand all this if "by a Redirect Agent" would be removed in the first paragraph.
OLD:
   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection by a Redirect
   agent MUST be specified as part of functionality supported by a
   Diameter application.

NEW:
   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection MUST be 
   specified as part of functionality supported by a Diameter application.

But then, if it doesn't apply to a Redirect Agent, then why do we have this paragraph
   However, despite the change in executing
   role, the behaviour itself is a slight modification of the behaviour
   of a redirect agent as described in Section 2.8.3 of [RFC6733]. 


3.
   An application can specify that realm-based redirection operates only
   on the initial message of a session, or on any message of a session.

"only the initial message" or "on any message of a session" = "on any message of a session", right?
Remove "only", that would make sense with the next sentence in the paragraph.
Same remark for the first paragraph in 3.2.1

4.
I thought about this use case:
   "consider the case where an operator has offered a specific
   service but no longer wishes to do so.  The operator has arranged for
   an alternative domain to provide the service."
Don't we need "Redirect-Max-Cache-Time" = "forever"?
Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is not present?
I could not find a definitive answer in the draft or in RFC 6733 

5.
      If the redirected request contained a Destination-Host AVP, that
      AVP is ignored by the redirecting server.

Pay attention that you update RFC 6733

Proposal
      If the redirected request contains a Result-Code AVP set to
      DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, 
      that Destination-Host AVP MUST be ignored by the redirecting server.

Or 
      When a directed request contains a Result-Code AVP set to
      DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP
      content MUST be ignored by the redirecting server.

6.
   A proxy conforming to this specification that receives an answer
   message with the Result-Code AVP set to
   DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the
   original request to a server in a realm identified by a Redirect-
   Realm AVP instance in the answer message, or MAY simply forward the
   message toward the client. 

It MUST do one of the two things, I guess. Otherwise, doing nothing is also a valid option according to the text.
Please mention it.


7.
Section 3.2.2
And what if all point of the procedure fail, for all realms, what should happen?
DIAMETER_REDIRECT_INDICATION to the client?


Editorial
- Redirect agent versus redirect agent
- Redirecting Server is a new term AFAICT, and is not really defined (even if we can guess).
Is this intentional?


Regards, Benoit


--------------030001030705010903080608-- From aland@deployingradius.com Tue Jul 23 17:06:19 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 CB0E411E818D for ; Tue, 23 Jul 2013 17:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MikUyDdqgbvZ for ; Tue, 23 Jul 2013 17:06:13 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 861B011E8195 for ; Tue, 23 Jul 2013 17:06:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C2C2A22400CA for ; Wed, 24 Jul 2013 02:05:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70FuRKDjrhGr for ; Wed, 24 Jul 2013 02:05:17 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 3C15C224009D for ; Wed, 24 Jul 2013 02:05:17 +0200 (CEST) Message-ID: <51EF1A3D.802@deployingradius.com> Date: Tue, 23 Jul 2013 20:05:17 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Review of draft-tschofenig-dime-overload-arch-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:06:19 -0000 Hannes asked me to review the documents. While I've been avoiding Diameter, many of the principles are similar across AAA protocols. Over all the document seems reasonable, and describes a consistent architecture. My biggest issue is Section 4.3, the "Exchange of Load Info" discussion. I have some concerns here. Such signaling doesn't work well across proxies. i.e. For the diagram in Section 4.3, the Diameter servers can signal load information to the load balancer. However, the load balancer does not signal load information to clients. Even if the load balancer did signal load to the client, what does it signal? It has to aggregate load information across all Diameter servers. It's not clear how that would be done. I discussed a potentially better system with Hannes earlier today. The idea is essentially a single queue, multiple-server method. It's similar to that used in some stores: http://puzzlor.editme.com/queue http://www.ask.com/answers/39346021/why-a-single-queue-with-multiple-servers-performs-better-than-each-server-having-their-own-queue The method requires no feedback from the server to the load balancer. The load balancer simply monitors requests and responses. The algorithm can be implemented by a load balancer, or a client which has multiple home servers. The idea (in short) is to keep track of a number C, which is the count of requests sent to a home server which have not yet seen a response. The goal is to keep C the same across all N home servers in a load balance pool. When a new request comes in, the load balancer chooses a home server H with the lowest C value, and increments C. If there are multiple home servers with the same lowest C value, one is chosen at random. The result is that servers require no additional signaling to the load balancer. Offered load is spread evenly across home servers of equal responsiveness. Where one home server accepts more load than the others, it is sent more offered load. The rest of the document involves signaling of overload information. Signaling overload is more useful than signaling load-balance information. However, I think statements like the following in 5.2.3 are inflexible: INCREASING_OVERLOAD 1 The Diameter server uses this value to inform the client that overload has increased and that the Diameter client shall decrease the sending rate into half (calculated over the last 10 minutes). Why would the sending rate decrease by half? Why not any other value? It may be better for the Diameter server to simply respond with a message saying "I'm busy. Retry this request in N seconds". That message solves two purposes. One, it signals overload, which is a good thing. Two, it allows the server to selectively control the clients back-off method. Experience shows that making decisions in the server is simpler and more flexible than making decisions in the client. The only issue I see here is that this signaling would have to be in-band. i.e. a Diameter client sends a request X, and instead of receiving a normal reply, it receives an error reply indicating the re-transmission timer. This may be fit in with the current diameter practice. I'm not familiar enough to say for sure. The algorithm for the load-balancing solution is simple. It's been implemented in at least one AAA server for a decade, with no known issues. The algorithm for retransmission signaling is less obvious. Both the information to be tracked, and the algorithm are unknown. I believe that these approaches would be simpler and more robust than alternatives. I'll spend some time modeling various algorithms for the retransmission signaling. The solution seems simple to me, but is also not obvious right now. Alan DeKok. From ben@nostrum.com Tue Jul 23 19:11:24 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 0CA3C11E81B9 for ; Tue, 23 Jul 2013 19:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpBWgtxT6G4d for ; Tue, 23 Jul 2013 19:11:23 -0700 (PDT) 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 F387611E81B6 for ; Tue, 23 Jul 2013 19:11:22 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6O2BFUA072149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jul 2013 21:11:16 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <51EF1A3D.802@deployingradius.com> Date: Tue, 23 Jul 2013 21:11:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EF1A3D.802@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-tschofenig-dime-overload-arch-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 02:11:24 -0000 Hi Alan, At risk of this being a big thing to ask--could you also take a look at = draft-roach-dime-overload-ctrl-03? It would be useful to have your = opinion on all the current Diameter overload control proposals. draft-ietf-dime-overload-reqs-09 might also be useful for context on the = discussion so far. Thanks! Ben. On Jul 23, 2013, at 7:05 PM, Alan DeKok = wrote: > Hannes asked me to review the documents. While I've been avoiding > Diameter, many of the principles are similar across AAA protocols. >=20 > Over all the document seems reasonable, and describes a consistent > architecture. >=20 > My biggest issue is Section 4.3, the "Exchange of Load Info" > discussion. I have some concerns here. >=20 > Such signaling doesn't work well across proxies. i.e. For the = diagram > in Section 4.3, the Diameter servers can signal load information to = the > load balancer. However, the load balancer does not signal load > information to clients. >=20 > Even if the load balancer did signal load to the client, what does it > signal? It has to aggregate load information across all Diameter > servers. It's not clear how that would be done. >=20 >=20 > I discussed a potentially better system with Hannes earlier today. > The idea is essentially a single queue, multiple-server method. It's > similar to that used in some stores: >=20 > http://puzzlor.editme.com/queue > = http://www.ask.com/answers/39346021/why-a-single-queue-with-multiple-serve= rs-performs-better-than-each-server-having-their-own-queue >=20 > The method requires no feedback from the server to the load balancer. > The load balancer simply monitors requests and responses. The > algorithm can be implemented by a load balancer, or a client which has > multiple home servers. >=20 > The idea (in short) is to keep track of a number C, which is the = count > of requests sent to a home server which have not yet seen a response. > The goal is to keep C the same across all N home servers in a load > balance pool. >=20 > When a new request comes in, the load balancer chooses a home server = H > with the lowest C value, and increments C. If there are multiple home > servers with the same lowest C value, one is chosen at random. >=20 > The result is that servers require no additional signaling to the = load > balancer. Offered load is spread evenly across home servers of equal > responsiveness. Where one home server accepts more load than the > others, it is sent more offered load. >=20 >=20 > The rest of the document involves signaling of overload information. > Signaling overload is more useful than signaling load-balance > information. However, I think statements like the following in 5.2.3 > are inflexible: >=20 > INCREASING_OVERLOAD 1 The Diameter server uses this value > to inform the client that overload has increased and that the > Diameter client shall decrease the sending rate into half > (calculated over the last 10 minutes). >=20 > Why would the sending rate decrease by half? Why not any other = value? >=20 > It may be better for the Diameter server to simply respond with a > message saying "I'm busy. Retry this request in N seconds". That > message solves two purposes. One, it signals overload, which is a = good > thing. Two, it allows the server to selectively control the clients > back-off method. >=20 > Experience shows that making decisions in the server is simpler and > more flexible than making decisions in the client. The only issue I = see > here is that this signaling would have to be in-band. >=20 > i.e. a Diameter client sends a request X, and instead of receiving a > normal reply, it receives an error reply indicating the = re-transmission > timer. This may be fit in with the current diameter practice. I'm = not > familiar enough to say for sure. >=20 >=20 > The algorithm for the load-balancing solution is simple. It's been > implemented in at least one AAA server for a decade, with no known = issues. >=20 > The algorithm for retransmission signaling is less obvious. Both the > information to be tracked, and the algorithm are unknown. >=20 > I believe that these approaches would be simpler and more robust than > alternatives. >=20 > I'll spend some time modeling various algorithms for the > retransmission signaling. The solution seems simple to me, but is = also > not obvious right now. >=20 > Alan DeKok. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jean-jacques.trottin@alcatel-lucent.com Wed Jul 24 05:59: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 5733B11E80E4 for ; Wed, 24 Jul 2013 05:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7XwPdmJ1llF for ; Wed, 24 Jul 2013 05:59:53 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B3E4111E80E0 for ; Wed, 24 Jul 2013 05:59:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6OCxo2e019610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jul 2013 07:59:52 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6OCxkVL030031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 14:59:49 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 14:59:46 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: AQHOh66wGuip22BE/EGIiiTArSzZUplyMAiAgAGThNA= Date: Wed, 24 Jul 2013 12:59:45 +0000 Message-ID: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> 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.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 24 Jul 2013 12:59:59 -0000 DQpEZWFyIGFsbA0KDQpJIGhlcmVhZnRlciBhZGQgc29tZSBjb21tZW50cyBvbiB0d28gb25lcyBt YWRlIGluIHByZXZpb3VzIG1haWxzLg0KDQotIHRoZXJlIHdhcyB0aGUgY29tbWVudCAiIEknbSBu b3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW1wbGljaXQgc2NvcGUgaXMgaW4gSGFubmVz J3MgZHJhZnQiLi4gIEkgYWdyZWUgaXQgd291bGQgYmUgZ29vZCBIYW5uZXMgdG8gY2xhcmlmeSBo aXMgbmV3IHByb3Bvc2FsLiBGcm9tIG15IG93biByZWFkaW5nIGluIGRyYWZ0LXRzY2hvZmVuaWct ZGltZS1vdmVybG9hZC1waWdneWJhY2tpbmcgaW4gIDMuMjoNCiAgIC4uLiB0aGUgRGlhbWV0ZXIN CiAgIHNlcnZlciAob3IgYSBwcm94eSwgLi4uLikgbWF5IGRlY2lkZSB0byBjb21tdW5pY2F0ZSB0 byB0aGUgRGlhbWV0ZXINCiAgIGNsaWVudCB0byByZWplY3Qgc29tZSBvciBldmVuIGFsbCBEaWFt ZXRlciByZXF1ZXN0cy4gVGhlIERpYW1ldGVyDQogICBzZXJ2ZXIgZG9lcyBzbyBieSBhZGRpbmcg dGhlIE92ZXJsb2FkLUluZm8gQVZQLCB3aGljaCBjb250YWlucyB0aGUNCiAgIE92ZXJsb2FkIGFu ZCB0aGUgUGVyaW9kLU9mLVZhbGlkaXR5IEFWUC4NCg0KVGhlbiB0aGUgb3ZlcmxvYWQgQVZQIGlu ZGljYXRlcyB0byB0aGUgY2xpZW50IHRoZSBhbW91bnQgb2YgdHJhZmZpYyB0byBkZWNyZWFzZSBv ciB0byBpbmNyZWFzZS4gU28gZnJvbSBteSB1bmRlcnN0YW5kaW5nLCBpdCBpcyBzaW1pbGFyIHRv IHRoZSBpbXBsaWNpdCBzY29wZSBJIGhhdmUgZGVzY3JpYmVkIGFzIHRoZSBwaWdneWJhY2tlZCBv dmVybG9hZCBpbmZvIGlzIHJlbGF0ZWQgdG8gdGhlIG1lc3NhZ2UgdHJhbnNwb3J0aW5nIGl0LCBh bmQgaW4gY29uc2VxdWVuY2UgZG9lcyBub3QgcmVxdWlyZSB0byBpbmRpY2F0ZSBhbiBleHBsaWNp dCBzY29wZS4gDQpJIGhhdmUgb3RoZXIgdmlld3Mgb24gdGhlIGNvbnRlbnQgb2YgdGhlIG92ZXJs b2FkIGluZm8gd2hlcmUgIEkgYW0gaW4gZmF2b3VyIG9mIGFuIG92ZXJsb2FkIGluZm8gaW5kaWNh dGluZyBhICUgb2YgdHJhZmZpYyByZWR1Y3Rpb24gdG8gYmUgYXBwbGllZC4gSSBhbHNvIGNvbnNp ZGVyIHRoZSBvdmVybGFvZCBpbmZvIGlzIHVzZWQgYnkgdGhlIHRocm90dGxpbmcgZW50aXR5IHdo aWNoIG1heSBiZSB0aGUgY2xpZW50IG9yIGFuIGludGVybWVkaWF0ZSBEQS4gSGFubmVzIG9ubHkg bWVudGlvbnMgdGhlIGNsaWVudC4NCg0KLSBhYm91dCB0aGUgY29tbWVudCAiZG8geW91IG1lYW4g YSBkZWZhdWx0PyAodGhhdCBpcywgb25lIHRoYXQgYXBwbGllcyBpZiBubyBzY29wZSBpcyBleHBs aWNpdGx5IGluY2x1ZGVkKT8iLiBUaGUgaW1wbGljaXQgc2NvcGUgSSBoYXZlIGRlc2NyaWJlZCBp cyBub3QgYSBkZWZhdWx0IHNjb3BlLCBpbiB0aGUgYWJvdmUgbWVhbmluZy4gSXQgaXMgaW1wbGlj aXQgYmVjYXVzZSBpdCBhcHBsaWVzIHRvIHRoZSB0cmFmZmljIHRvIHdoaWNoIHRoZSBtZXNzYWdl IGNvbnZleWluZyB0aGUgb3ZlcmxvYWQgaW5mbyBiZWxvbmdzLiBUaGlzIHNjb3BlIGlzIG5vdCBl eGNsdXNpdmUgb2Ygb3RoZXIgc2NvcGVzLCBidXQgZm9yIHRoZSBtYW55IGNhc2VzIHRoYXQgaXQg Y292ZXJzIGJ5IGl0c2VsZiwgIEkgZG8gbm90IGZvcmVzZWUgIHRvIHVzZSBpdCBpbiBjb25qdW5j dGlvbiB3aXRoIG90aGVycy4gQXMgbWVudGlvbmVkLCBJIHdvdWxkIGxpa2UgdG8ga25vdyB1c2Ug Y2FzZXMsIHRoYXQgdGhpcyBpbXBsaWNpdCBzY29wZSB3aWxsIG5vdCBjb3ZlciBhbmQgd2hpY2gg b3RoZXIgc2NvcGVzIG9yIGV4dGVuc2lvbnMgd291bGQgYmUgcmVxdWlyZWQuDQoNCkJlc3QgcmVn YXJkcw0KDQpKSmFjcXVlcyANCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6 IGRpbWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBCZW4gQ2FtcGJlbGwNCkVudm95w6nCoDogbWFyZGkgMjMganVpbGxldCAyMDEz IDE2OjI1DQrDgMKgOiBTaGlzaHVmZW5nDQpDY8KgOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgZGlt ZUBpZXRmLm9yZzsgQkVSUlksIE5pZ2VsIChOaWdlbCk7IEJlc3NpcywgVGhpZXJyeSAoVGhpZXJy eSkNCk9iamV0wqA6IFJlOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBEZWZhdWx0ICJJbXBs aWNpdCIgU2NvcGUNCg0KT29wcywgbGVmdCBvdXQgYSBjb21tZW50LS1zZWUgaW5saW5lOg0KDQpP biBKdWwgMjMsIDIwMTMsIGF0IDk6MTEgQU0sIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29t PiB3cm90ZToNCg0KPiBIaSBTdXNhbiwNCj4gDQo+IElmIHRoZXJlIGlzIG5vIGRpcmVjdCBjb25u ZWN0aW9uLCB0aGVuIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBub24tYWRqYWNlbnQgb3Zlcmxv YWQgY29udHJvbCBjYXNlLiBUaGF0J3Mgbm90ICh5ZXQpIGNvdmVyZWQgYXQgYWxsIGluIHRoZSBv cmlnaW5hbCB0d28gcHJvcG9zYWxzLiBJdCdzIG5vdCBjbGVhciB0byBtZSBpZiBIYW5uZXMncyBw cm9wb3NhbCBpcyBpbnRlbmRlZCB0byBkbyBzby4NCj4gDQo+IEhhdmUgeW91IChhbmQgb3RoZXJz KSBoYWQgYSBjaGFuY2UgdG8gcmVhZCB0aGUgbm9uLWFkamFjZW50IHNlY3Rpb24gaW4gZHJhZnQt Y2FtcGJlbGwtZGltZS1vdmVybG9hZC1pc3N1ZXMtMDE/IFRoZSBncm91cCBoYXMgaGFkIHNvbWUg ZGlzY3Vzc2lvbiBhYm91dCB0aGUgc2NvcGVzIGFuYWx5c2lzIGluIHRoYXQgZHJhZnQsIGJ1dCBu byBvbmUgaGFzIGNvbW1lbnRlZCBtdWNoIG9uIHRoZSBub24tYWRqYWNlbnQgb3ZlcmxvYWQgY29u dHJvbCBhbmFseXNpcy4NCg0KSW4gcGFydGljdWxhciwgSSBkbyB0aGluayBhbnkgImRlZmF1bHQi IHNjb3BlcyB3b3VsZCBiZSBkaWZmZXJlbnQgZm9yIG5vbi1hZGphY2VudCB0aGFuIGFkamFjZW50 IG92ZXJsb2FkIGNvbnRyb2wuICJDb25uZWN0aW9uIiBpcyB1c2VsZXNzIGZvciBub24tYWRqYWNl bnQsIGJ1dCBtYXkgYmUgdGhlIG1vc3QgdXNlZnVsIGZvciBhZGphY2VudC4gV2UgbWF5IG5lZWQg dG8gcnVsZSBvdXQgdGhlIFBlZXIgKG9yIEhvc3QpIHNjb3BlIGFuZCB0aGUgQ29ubmVjdGlvbiBz Y29wZSBlbnRpcmVseSBmb3Igbm9uLWFkamFjZW50IHVzZS4NCg0KSSBzdGlsbCBoYXZlIGNvbmNl cm5zIGFib3V0IHVzaW5nIGEgY29tYmluZWQgc2NvcGUgZm9yIHRoZSBkZWZhdWx0LCB0aG91Z2gu IEknZCByYXRoZXIgcGljayBzb21ldGhpbmcgc2ltcGxlIHRvIGFjdCBvbiwgaS5lLiBub3QgcmVx dWlyaW5nIHRoZSByZWFjdGluZyBub2RlIHRvIGx1Y2sgYXQgc2V2ZXJhbCBhc3BlY3RzIG9mIGEg cmVxdWVzdCB0byBkZXRlcm1pbmUgaWYgaXQgbWF0Y2hlcyB0aGUgc2NvcGUuIEVzc2VudGlhbGx5 LCBJJ20gY29uY2VybmVkIGFib3V0IF9kZWZhdWx0aW5nXyB0byByZXF1aXJpbmcgYSBib29sZWFu IGV4cHJlc3Npb24gY2hlY2sgb24gZWFjaCBhbmQgZXZlcnkgcmVxdWVzdC4NCg0KPiANCj4gSSBh bSByZWFzb25hYmx5IG9rYXkgd2l0aCBzYXlpbmcgbm8gc3BlY2lmaWMgc2NvcGUgaXMgcmVxdWly ZWQgYnkgdGhlIGJhc2UgbWVjaGFuaXNtLCBhcyBsb25nIGFzIHdlIChjb250aW51ZSB0bykgbGV0 IG5vZGVzIGRlY2xhcmUgd2hhdCB0aGV5IGNhbiByZWNlaXZlLiBUaGUgd29ya2luZyBncm91cCBz aG91bGQgZGlzY3VzcyB3aGV0aGVyIHdlIG1pZ2h0IHdhbnQgYXQgbGVhc3Qgb25lIG1hbmRhdG9y eS10by1pbXBsZW1lbnQgc2NvcGUgdG8gdHJ5IHRvIGF2b2lkICJpc2xhbmRzIiBvZiBpbnRlcm9w ZXJhYmlsaXR5LiBJIHdvbid0IGJlIHRvbyB1bmhhcHB5IHdoaWNoZXZlciB3YXkgd2UgZ28gb24g dGhhdCwgYXMgbG9uZyBhcyB3ZSB1bmRlcnN0YW5kIHRoZSBpbXBsaWNhdGlvbnMuDQo+IA0KPiBU aGFua3MhDQo+IA0KPiBCZW4uDQo+IA0KPiANCj4gT24gSnVsIDIzLCAyMDEzLCBhdCAyOjU3IEFN LCBTaGlzaHVmZW5nIChTdXNhbikgPHN1c2FuLnNoaXNodWZlbmdAaHVhd2VpLmNvbT4gd3JvdGU6 DQo+IA0KPj4gSGkgQmVuLA0KPj4gDQo+PiBJJ20gbm90IHN1cmUgaWYgImltcGxpY2l0IiBtZWFu cyAiZGVmYXVsdCIsIGJ1dCBzaG91bGQgYmUgdmVyeSBzaW1pbGFyIHRvIGVhY2ggb3RoZXIgb24g dGhpcyBwb2ludC4NCj4+IA0KPj4gSW4gbXkgdW5kZXJzdGFuZGluZywgIkNvbm5lY3Rpb24iIHNj b3BlIGZvY3VzIG9uIHRyYW5zcG9ydCBjb25uZWN0aW9uIHdoaWNoIGlzIGxpbWl0ZWQgYmV0d2Vl biB0d28gYWRqYWNlbnQgcGVlcnMuIFdoaWxlIGluIDNHUFAgRGlhbWV0ZXIgYXBwbGljYXRpb25z LCB0aGUgaW1wb3J0YW50IHRoaW5nIGZvciBvdmVybG9hZCBjb250cm9sIGlzIHRvIGV4Y2hhbmdl IGxvYWQvb3ZlcmxvYWQgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciBmb3Igd2hpY2ggdGhlcmUg bWlnaHQgbm90IGJlIGRpcmVjdCB0cmFuc3BvcnQgY29ubmVjdGlvbi4gDQo+PiANCj4+IFRvIG1h a2UgdGhpbmdzIHNpbXBsZSBhbmQgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGluIElFVEYgbW9yZSBj b21tb24sIEkgd291bGQgcHJvcG9zZSB0byBub3QgaGF2ZSBhbnkgc2NvcGUgbWFuZGF0ZWQgYW5k IGxlYXZlIGl0IGZvciBhcHBsaWNhdGlvbnMgdG8gZGVjaWRlIGlmIGV4cGxpY2l0IHNjb3BlKHMp IGlzKGFyZSkgbmVlZGVkIG9yIGFuIGltcGxpY2l0IHNjb3BlIGNhbiBiZSBhcHBsaWVkLg0KPj4g DQo+PiBCZXN0IFJlZ2FyZHMsDQo+PiBTdXNhbg0KPj4gDQo+PiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+PiDlj5Hku7bkuro6IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0g DQo+PiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMjPml6UgNTowOA0KPj4g5pS25Lu25Lq6OiBT aGlzaHVmZW5nIChTdXNhbikNCj4+IOaKhOmAgTogRE9MTFksIE1BUlRJTiBDOyBkaW1lQGlldGYu b3JnOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgQkVSUlksIE5pZ2VsIChOaWdlbCk7IEJlc3Npcywg VGhpZXJyeSAoVGhpZXJyeSkNCj4+IOS4u+mimDogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9h ZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KPj4gDQo+PiBIaSBTdXNhbiwNCj4+IA0KPj4g V2hlbiB5b3Ugc2F5ICJpbXBsaWNpdCIgc2NvcGUsIGRvIHlvdSBtZWFuIGEgZGVmYXVsdD8gKHRo YXQgaXMsIG9uZSB0aGF0IGFwcGxpZXMgaWYgbm8gc2NvcGUgaXMgZXhwbGljaXRseSBpbmNsdWRl ZCk/IEknbSBub3Qgb3Bwb3NlZCB0byBoYXZpbmcgc3VjaCBhIGNvbW1lbnQsIGJ1dCBJIHRoaW5r IHdlIG5lZWQgdG8gbG9vayBtb3JlIGNsb3NlbHkgYXQgaG93IERpYW1ldGVyIHNlcnZlcnMgdGVu ZCB0byBhY3R1YWxseSBiZSBkZXBsb3llZCwgYW5kIHdoZXJlIHdlIHNhdmUgY29tcGxleGl0eS4g UmVhbG0gKyBBcHBsaWNhdGlvbiArIERlc3RpbmF0aW9uLUhvc3QgKyBPcmlnaW4tSG9zdCBpcyBh IGZhaXJseSBjb21wbGV4IHNjb3BlLiBCdXQgdGhlIGNvbXBsZXhpdHkgaXMgbm90IGluIGhvdyB5 b3UgZXhwcmVzcyBpdCBvbiB0aGUgd2lyZS0tdGhhdCdzIHByZXR0eSBlYXN5LiBJdCdzIGFsc28g bm90IGhvdyB5b3UgaW50ZXJwcmV0IHRoZSBzY29wZS0tdGhhdCdzIGEgb25lIHRpbWUgYWN0aW9u IHBlciBvdmVybG9hZCByZXBvcnQuIFRoZSByZWFsbHkgaGFyZCBwYXJ0IGlzIHRoZSBkZWNpc2lv biBmdW5jdGlvbiB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFwcGxpZXMgdG8gZXZlcnkgc2luZ2xl IHJlcXVlc3QgdG8gZGV0ZXJtaW5lIGlmIHRoZSBzY29wZSBhcHBsaWVzIHRvIGl0LiBBbmQgdGhh dCdzIHRydWUgd2hldGhlciB0aGUgc2NvcGUgaXMgaW1wbGljaXRseSBvciBleHBsaWNpdGx5IGlu Y2x1ZGVkIGluIGFuIG92ZXJsb2FkIHJlcG9ydC4NCj4+IA0KPj4gSXQgc2VlbXMgdG8gbWUgdGhh dCBpZiB3ZSBkZWZpbmUgYSBkZWZhdWx0IHNjb3BlLCBpdCBzaG91bGQgYmUgYm90aCBjb21tb25s eSB1c2VkIGFuZCBzaW1wbGUuIFRoZSBvbmUgdGhhdCB5b3UgYW5kIEpKIGhhdmUgcHJvcG9zZWQg bWF5IGJlIGNvbW1vbiwgYnV0IGl0J3Mgbm90IHNpbXBsZS4gSSB0aGluayB0aGlzIG5lZWRzIG1v cmUgYW5hbHlzaXMsIGJ1dCBzbyBmYXIgSSB0aGluayB0aGF0ICJDb25uZWN0aW9uIiBpcyB0aGUg c3Ryb25nZXN0IGNhbmRpZGF0ZSBmb3IgYmVpbmcgYm90aCBjb21tb24gYW5kIHNpbXBsZS4NCj4+ IA0KPj4gDQo+PiANCj4+IE9uIEp1bCAyMSwgMjAxMywgYXQgOTo1MyBQTSwgU2hpc2h1ZmVuZyAo U3VzYW4pIDxzdXNhbi5zaGlzaHVmZW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gSGVs bG8gYWxsLA0KPj4+IA0KPj4+IEkgd291bGQgc3VwcG9ydCB0byBoYXZlIGFuIGltcGxpY2l0IHNj b3BlIGxpbWl0ZWQgdG8gd2hhdCdzIGNvbnRhaW5lZCBpbiB0aGUgbWVzc2FnZSBpdHNlbGYsIGku ZS4gYXMgbWVudGlvbmVkIGJ5IEpKLCBzcGVjaWZpYyBhcHBsaWNhdGlvbiwgc3BlY2lmaWMgaG9z dCwgYW5kIHNwZWNpZmljIGRlc3RpbmF0aW9uLiBPciB5b3UgY2FuIGNhbGwgaXQgYXMgYSBjb21i aW5hdGlvbiBvZiAiRGVzdGluYXRpb24gSG9zdC9kZXN0aW5hdGlvbiByZWFsbSwgb3JpZ2luIEhv c3Qvb3JpZ2luIHJlYWxtLCBmb3IgYSBnaXZlbiBBcHBsaWNhdGlvbiBJRCIuIEZyb20gbXkgcG9p bnQgb2YgdmlldywgYSB2ZXJ5IHNpbXBseSB1c2UgY2FzZSBvZiBvdmVybG9hZCBjb250cm9sIGZv ciAzR1BQIERpYW1ldGVyIGFwcGxpY2F0aW9ucyBpcyB0aGF0IHRoZSBzZXJ2ZXIgc2VuZHMgaXRz IGxvYWQvb3ZlcmxvYWQgaW5mb3JtYXRpb24gdG8gdGhlIGNsaWVudCwgdGhlIGNsaWVudCBkZWNp ZGVzIHRvIHRocm90dGxlIG9yIG5vdCBtZXNzYWdlcyByZWxhdGVkIHRvIHRoZSBjb3JyZXNwb25k aW5nIGFwcGxpY2F0aW9uIHRvIHRoZSBzZXJ2ZXIuIEUuZy4gZm9yIDNHUFAgUzZhLCBhZnRlciB1 cGRhdGUgbG9jYXRpb24gcHJvY2VkdXJlLCB0aGUgTU1FIHdvdWxkIHN0b3JlIG9uZSBzcGVjaWZp YyBIU1MgaWRlbnRpdHkgZm9yIGVhY2ggVUUgYXR0YWNoZWQgZm9yIGVhc3kgcm91dGluZyBvZiBz dWJzZXF1ZW50IG1lc3NhZ2VzLiBUbyB0aGlzIE1NRSwgaXQgb25seSBjYXJlcyBpZiB0aGlzIEhT UyBpcyBvdmVybG9hZGVkLiBUaGlzIGRvZXMgbm90IHByZXZlbnQgdG8gZGVwbG95IERpYW1ldGVy IEFnZW50cyBmb3IgbG9hZCBiYWxhbmNpbmcsIHdoaWNoIGNhbiByZWRpcmVjdCB0aGUgcmVxdWVz dHMgdG8gb3RoZXIgbm9uLW92ZXJsb2FkaW5nIHNlcnZlcnMgb3IgY2hhbmdlIHRoZSBsZXZlbCBv ZiB0aGUgb3ZlcmxvYWQgc2l0dWF0aW9uIG9mIHRoZSBzZXJ2ZXIuIEJ1dCB0byB0aGUgY2xpZW50 LCBpdCBjYW4gYWx3YXlzIHNlZSBvbmUgc3BlY2lmaWMgc2VydmVyIGF0IGEgc3BlY2lmaWMgdGlt ZS4NCj4+PiANCj4+PiBCZXN0IFJlZ2FyZHMsDQo+Pj4gU3VzYW4NCj4+PiANCj4+PiAtLS0tLemC ruS7tuWOn+S7ti0tLS0tDQo+Pj4g5Y+R5Lu25Lq6OiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5A bm9zdHJ1bS5jb21dIA0KPj4+IOWPkemAgeaXtumXtDogMjAxM+W5tDfmnIgyMOaXpSA1OjM4DQo+ Pj4g5pS25Lu25Lq6OiBET0xMWSwgTUFSVElOIEMNCj4+PiDmioTpgIE6IGRpbWVAaWV0Zi5vcmc7 IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBCRVJSWSwgTmlnZWwgKE5pZ2VsKTsgQmVzc2lzLCBUaGll cnJ5IChUaGllcnJ5KQ0KPj4+IOS4u+mimDogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9hZCAt IERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KPj4+IA0KPj4+IEJ5ICJpbXBsaWNpdCIgc2NvcGUs IGFyZSB3ZSByZWFsbHkgdGFsa2luZyBhYm91dCBhICJkZWZhdWx0IiBzY29wZT8gVGhhdCBpcywg YSBzY29wZSBhc3N1bWVkIHRvIGJlIGFjdGl2ZSBpZiBubyBzY29wZSBpcyByZXBvcnRlZCwgYnV0 IGlzIG92ZXJyaWRkZW4gaWYgYW55IGV4cGxpY2l0IHNjb3BlIGlzIHJlcG9ydGVkPw0KPj4+IA0K Pj4+IElmIHNvLCBJIGRvbid0IG9iamVjdCBpbiBwcmluY2lwbGUuIEJ1dCBJIHRoaW5rIHRoZSBj aG9pY2Ugb2YgYSBkZWZhdWx0IHNob3VsZCBiZSB0aGUgc2NvcGUgdGhhdCB3ZSB0aGluayB3aWxs IGJlIHVzZWQgdGhlIG1vc3Qgb2Z0ZW4uIA0KPj4+IA0KPj4+IFlvdSBtZW50aW9uIEFwcGxpY2F0 aW9uLUlkLiBUaGF0IG1ha2VzIHNlbnNlIGZvciBhIGRlZmF1bHQgaWYgeW91IGV4cGVjdCBBcHBs aWNhdGlvbi1JZCB0byBhY3R1YWxseSBiZSBzZWxlY3RpdmUgbW9zdCBvZiB0aGUgdGltZSwgdGhh dCBpcywgeW91IGV4cGVjdCBub2RlcyB0byAgc2VuZCBsb3RzIG9mIHJlcXVlc3RzIHdpdGggZGlm ZmVyZW50IEFwcGxpY2F0aW9uLUlkcyB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbi4gVGhhdCdzIHBy b2JhYmx5IHRydWUgaWYgdGhlIGRlc3RpbmF0aW9uIGlzIGFuIGFnZW50IHRoYXQgcm91dGVzIHJl cXVlc3QgZm9yIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24uIE9UT0gsIGRvIHlvdSB1c3VhbGx5 IHNlZSBhIGNsaWVudCBzZW5kIHJlcXVlc3RzIGZvciBtb3JlIHRoYW4gb25lIGFwcGxpY2F0aW9u IG9uIGEgc2luZ2xlIHRyYW5zcG9ydCBsYXllciBjb25uZWN0aW9uPw0KPj4+IA0KPj4+IE15IGtu ZWVqZXJrIHJlYWN0aW9uIGlzIHRvIHRoaW5rIHRoYXQgdGhlIG1vc3QgY29tbW9ubHkgdXNlZCBz Y29wZSB3aWxsIGJlICJjb25uZWN0aW9uIi4NCj4+PiANCj4+PiBPVE9ILCBBcHBsaWNhdGlvbi1J ZCBvciBDb25uZWN0aW9uIGNhbiBlYWNoIGJlIGluZGljYXRlZCBieSBhIHNpbmdsZSBBVlAuIERv IHdlIGdhaW4gbXVjaCBpbiBhbGxvd2luZyBpdCB0byBiZSBkZWZhdWx0ZWQ/IEpKYWNxdWVzIHBy ZXZpb3VzbHkgbWVudGlvbmVkICJEZXN0aW5hdGlvbiBIb3N0L2Rlc3RpbmF0aW9uIHJlYWxtLCBv cmlnaW4gSG9zdC9vcmlnaW4gcmVhbG0sIGZvciBhIGdpdmVuIEFwcGxpY2F0aW9uIElEIiwgd2hp Y2ggaXMgYSBjb21wb3NpdGUgdGhhdCB3b3VsZCByZXF1aXJlIDQtNSBzY29wZSBBVlBzIHRvIGV4 cHJlc3MuIEkgZG9uJ3QgdGhpbmsgdGhhdCBjb21iaW5hdGlvbiB3b3VsZCBuZWNlc3NhcmlseSBt YWtlIGEgZ29vZCBkZWZhdWx0LCBidXQgSSBjYW4gc2VlIG9uZSBtaWdodCB3YW50IHRvIGJlIGFi bGUgdG8gZXhwcmVzcyBpdCAoYW5kIG1vcmUgaW1wb3J0YW50bHksIG5lZ290aWF0ZSB0aGF0IHlv dSBjYW4gYWNjZXB0IHRoYXQgY29tYmluYXRpb24sIGJ1dCBub3Qgb3RoZXIgY29tYmluYXRpb25z IG9mIHRoZSBzYW1lIHNjb3Blcy4pIFdlIGNvdWxkIGFsd2F5cyBhZGQgc29tZSBuZXcgc2NvcGUt dHlwZSB0aGF0IG1lYW5zICJUaGlzIGRlc3RpbmF0aW9uLWhvc3QsIFRoaXMgYXBwbGljYXRpb24t SWQiLCBldGMuIChJJ20gbm90IHN1Z2dlc3Rpbmcgd2UgZG8gc28gbm93LCBidXQgc2luY2Ugd2Ug aW50ZW5kZWQgc2NvcGVzIHRvIGJlIGV4dGVuc2libGUsIHdlIGNvdWxkIGFsd2F5cyBhZGQgdGhh dCBkb3duIHRoZSByb2FkIGlmIHdlIGZpbmQgdGhlIG5lZWQgdG8gZG8gc28uDQo+Pj4gDQo+Pj4g DQo+Pj4gT24gSnVsIDE5LCAyMDEzLCBhdCA0OjE4IFBNLCAiRE9MTFksIE1BUlRJTiBDIiA8bWQz MTM1QGF0dC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiBCZW4vYWxsLA0KPj4+PiANCj4+Pj4gSSBi ZWxpZXZlIHRoZXJlIGNvdWxkIGJlIGFuICJpbXBsaWNpdCIgc2NvcGUgdGhhdCBpcyBjb21tb24g dG8gYWxsIHVzZSBjYXNlcyAoZS5nLCBBcHBsaWNhdGlvbi1JRCkuDQo+Pj4+IA0KPj4+PiBSZWdh cmRzLA0KPj4+PiANCj4+Pj4gTWFydGluDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+PiBGcm9tOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaW1lLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4gQ2FtcGJlbGwNCj4+Pj4gU2VudDogRnJp ZGF5LCBKdWx5IDE5LCAyMDEzIDQ6NTUgUE0NCj4+Pj4gVG86IFRST1RUSU4sIEpFQU4tSkFDUVVF UyAoSkVBTi1KQUNRVUVTKQ0KPj4+PiBDYzogRFJBR0UsIEtlaXRoIChLZWl0aCk7IGRpbWVAaWV0 Zi5vcmc7IEJFUlJZLCBOaWdlbCAoTmlnZWwpOyBCZXNzaXMsIFRoaWVycnkgKFRoaWVycnkpDQo+ Pj4+IFN1YmplY3Q6IFJlOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBEZWZhdWx0ICJJbXBs aWNpdCIgU2NvcGUNCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiBKdWwgMTksIDIwMTMsIGF0IDg6MDcg QU0sICJUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykiIDxqZWFuLWphY3F1ZXMu dHJvdHRpbkBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEhpIGFsbA0K Pj4+Pj4gDQo+Pj4+PiBJIGNvbWUgYmFjayBvbiBteSBtYWlsIEkgc2VudCB5b3UgbGFzdCBUdWVz ZGF5IG9uIGFuIGltcGxpY2l0IHNjb3BlIC4gQXMgSSBzYWlkLCBJIGFtIGNvbmNlcm5lZCB3aXRo IHRoZSBudW1iZXIgb2Ygc2NvcGVzIGFuZCB0aGVpciBjb21iaW5hdGlvbnMgaW4gdGhlIGRyYWZ0 LXJvYWNoIHNvbHV0aW9uICB3aGljaCBhZGRzIGNvbXBsZXhpdHksIGFuZCBmb3IgdGhpcyBzb2x1 dGlvbiBJIHByb3Bvc2VkIHRvIGNvbnNpZGVyIGFuIGltcGxpY2l0IHNjb3BlIHdoaWNoIGZvciBt ZSBzaG91bGQgZml0IG1hbnkgY2FzZXMuIA0KPj4+Pj4gDQo+Pj4+PiBIYW5uZXMgaGFzIGEgc2lt aWxhciBjb25jZXJuIGFuZCBpbiBoaXMgbmV3IHNvbHV0aW9uIGZvciBvdmVybG9hZCBoZSBmb2N1 c2VkIG9uIGEgbWluaW1hbCBtZWNoYW5pc20gd2hlcmUgdGhlcmUgaXMgIG5vIG1vcmUgZXhwbGlj aXQgc2NvcGVzLiBCZWhpbmQgdGhpcyBtaW5pbWFsIG1lY2hhbmlzbSwgdGhlcmUgaXMgYW4gaW1w bGljaXQgc2NvcGUgd2hpY2ggSSB0aGluayBpcyBub3QgZmFyIGZyb20gbWluZS4NCj4+Pj4gDQo+ Pj4+IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW1wbGljaXQgc2NvcGUgaXMg aW4gSGFubmVzJ3MgZHJhZnQuIA0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gRnJvbSB0aGVzZSBpbnB1 dHMsIEkgdGhpbmsgdGhlIGdyb3VwIHNob3VsZCBpbnZlc3RpZ2F0ZSBhIGJhc2ljIHZlcnNpb24g b2YgdGhlIG92ZXJsb2FkIGNvbnRyb2wgbWVjaGFuaXNtIHdoaWNoIGNvdWxkIGJlIGFsc28gcGFy dCBvZiB0aGUgZHJhZnQgcm9hY2ggc29sdXRpb24gYW5kIHNlZSB3aGljaCBleHRlbnNpb25zIGFy ZSBuZWVkZWQuDQo+Pj4+IA0KPj4+PiBJIGNvbmN1ciB3ZSBuZWVkIHRoZSBtb3N0IHNpbXBsZSBz b2x1dGlvbiB0aGF0IG1lZXRzIHRoZSByZXF1aXJlbWVudHMuIEJ1dCBJIHRoaW5rIHRoYXQsIHdp dGhvdXQgYXQgbGVhc3Qgc29tZSBjb25jZXB0IG9mIHNjb3BlcywgaXQncyBnb2luZyB0byBiZSB2 ZXJ5IGhhcmQgdG8gY29tZSB1cCB3aXRoIGEgbWVjaGFuaXNtIHRoYXQgZG9lc24ndCBkbyBtb3Jl IGhhcm0gdGhhbiBnb29kLiBFaXRoZXIgaXQgd2lsbCBpbmNyZWFzZSB0aGUgaW1wYWN0IG9mIGFu IG92ZXJsb2FkIGNvbmRpdGlvbiBieSBmb3JjaW5nIHJlcXVlc3RzIHRvIGJlIHJlamVjdGVkIHVu bmVjZXNzYXJpbHksIG9yIGl0IHdpbGwgY2F1c2UgY2xpZW50cyBhbmQgcmVsYXlzIHRvIGF0dGVt cHQgdG8gc2VuZCByZXF1ZXN0cyB0byBhbHRlcm5hdGUgZGVzdGluYXRpb25zLCB3aGljaCBhcmUg bGlrZWx5IGFsc28gb3ZlcmxvYWRlZC4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQmVz dCByZWdhcmRzDQo+Pj4+PiANCj4+Pj4+IEpKYWNxdWVzDQo+Pj4+PiANCj4+Pj4+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+Pj4gRGUgOiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpF QU4tSkFDUVVFUykgDQo+Pj4+PiBFbnZvecOpIDogbWFyZGkgMTYganVpbGxldCAyMDEzIDExOjEy DQo+Pj4+PiDDgCA6IGRpbWVAaWV0Zi5vcmcNCj4+Pj4+IENjIDogQkVSUlksIE5pZ2VsIChOaWdl bCk7IEJlc3NpcywgVGhpZXJyeSAoVGhpZXJyeSk7IERSQUdFLCBLZWl0aCAoS2VpdGgpDQo+Pj4+ PiBPYmpldCA6IFJFOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBEZWZhdWx0ICJJbXBsaWNp dCIgU2NvcGUNCj4+Pj4+IA0KPj4+Pj4gSGkgQmVuLCBFcmljIGFuZCBhbGwNCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiBBYm91dCB0aGUgaW1wbGljaXQgc2NvcGUsIEkgYW0gdGhpbmtpbmcgdG8gdGhl IG9uZSB1c2VkIGZvciBhbiBvdmVybG9hZCBpbmZvIHdoaWNoIHJlbGF0ZXMgdG8gdGhlIHRyYWZm aWMgdG8gd2hpY2ggdGhlIG1lc3NhZ2UgdHJhbnNwb3J0aW5nIHRoaXMgb3ZlcmxvYWQgaW5mbyBi ZWxvbmdzLCBtZWFuaW5nIHRoZSB0cmFmZmljIGJldHdlZW4gYSBEZXN0aW5hdGlvbiBIb3N0L2Rl c3RpbmF0aW9uIHJlYWxtLCBvcmlnaW4gSG9zdC9vcmlnaW4gcmVhbG0sIGZvciBhIGdpdmVuIEFw cGxpY2F0aW9uIElELiBUaGlzIHNjb3BlIGlzIGltcGxpY2l0bHkgZGVmaW5lZCBieSB0aGVzZSBB VlBzIG9mIHRoZSBtZXNzYWdlIGFuZCBkb2VzIG5vdCByZXF1aXJlIGEgY29tYmluYXRpb24gb2Yg U2NvcGUgQVZQcw0KPj4+Pj4gDQo+Pj4+PiBBbm90aGVyIHBvaW50IGlzIG9uIGhvdyB0byBsaW1p dCB0aGUgbnVtYmVyIG9mIHNjb3BlcyBhbmQgdGhlaXIgY29tYmluYXRpb25zLiBTdWNoIGEgbnVt YmVyIG9mIHBvc3NpYmlsaXRpZXMgaW5jcmVhc2UgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIG92ZXJs b2FkIGNvbnRyb2wgbWFuYWdlbWVudCwgd2hpY2ggaW5jcmVhc2VzIHRoZSByaXNrcy4gVGhlIGlt cGxpY2l0IHNjb3BlIGlzIGFuIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIGFzIGl0IGNhbiBiZSB1 c2VkIGluc3RlYWQgb2YgdGhlIG90aGVyIHNjb3BlcyBzdWNoIGFzIERlc3RpbmF0aW9uIEhvc3Qs IE9yaWdpbiBIb3N0LCBhcHBsaWNhdGlvbiBJRCwgY29ubmVjdGlvbiwgYW5kIHRoZWlyIGNvbWJp bmF0aW9ucyBpbiBtYW55IGNhc2VzLg0KPj4+Pj4gDQo+Pj4+PiBCZXN0IHJlZ2FyZHMNCj4+Pj4+ IA0KPj4+Pj4gSkphY3F1ZXMNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4+Pj4+IERlIDogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlt ZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEJlbiBDYW1wYmVsbA0KPj4+Pj4gRW52 b3nDqSA6IGx1bmRpIDE1IGp1aWxsZXQgMjAxMyAwMTowNA0KPj4+Pj4gw4AgOiBFcmljIE1jTXVy cnkNCj4+Pj4+IENjIDogZGltZUBpZXRmLm9yZw0KPj4+Pj4gT2JqZXQgOiBSZTogW0RpbWVdIERp YW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGljaXQiIFNjb3BlDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gT24gSnVsIDE0LCAyMDEzLCBhdCAzOjU5IFBNLCBFcmljIE1jTXVycnkgPGVtY211 cnJ5QGNvbXB1dGVyLm9yZz4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiBKdWwg MTQsIDIwMTMsIGF0IDEzOjAxICwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+IHdyb3Rl Og0KPj4+Pj4+IA0KPj4+Pj4+PiBPbiBKdWwgMTQsIDIwMTMsIGF0IDk6NDEgQU0sIEVyaWMgTWNN dXJyeSA8ZW1jbXVycnlAY29tcHV0ZXIub3JnPiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBI aSBNYXJ0aW4sDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRlY2huaWNhbGx5IHRoYXQgc2hvdWxkIGJl IHBvc3NpYmxlLiAgSSBoYXZlIHNvbWUgY29uY2VybiBhYm91dCBtaXhpbmcgaW1wbGljaXQgYW5k IGV4cGxpY2l0IHNjb3BlcyB0aG91Z2guICBUaGF0IGNvdWxkIGJlIGNvbmZ1c2luZy4gIEkgd291 bGQgdGhpbmsgaXQgd29uJ3QgYmUgdGhhdCBoYXJkIHRvIHB1dCB0aG9zZSB0d28gc2NvcGVzIGlu dG8gY29udHJvbCBpbmZvcm1hdGlvbiB0aGV5IGFwcGx5IHRvLiANCj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4gUGVyaGFwcyBvdGhlcnMgaGF2ZSB0aG91Z2h0cyBvbiBtaXhpbmcgaW1wbGljaXQgYW5kIGV4 cGxpY2l0IHNjb3Blcz8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBkZXBlbmRzIG9u IHdoYXQgd2UgbWVhbiBieSBpbXBsaWNpdCBzY29wZXMuIElzIGFuIGltcGxpY2l0IHNjb3BlIGEg ZGVmYXVsdCB0aGF0IGlzIHVzZWQgaWYgbm8gc2NvcGUgaW5kaWNhdG9ycyBhcmUgaW4gYW4gb3Zl cmxvYWQgcmVwb3J0PyBPciBpcyBpdCBhIHNjb3BlIHRoYXQgaXMgYXNzdW1lZCB0byBiZSBpbiBh bGwgcmVwb3J0cyBldmVuIGlmIG5vdCBpbmRpY2F0ZWQ/IEkgdGhpbmsgdGhlIGZpcnN0IF9taWdo dF8gbWFrZSBzZW5zZS4gVGhlIHNlY29uZCBydW5zIGFmb3VsIG9mIHlvdXIgY29uY2VybiBhYm91 dCBtaXhpbmcgaW1wbGljaXQgYW5kIGV4cGxpY2l0Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW4gZ2Vu ZXJhbCwgdGhvdWdoLCBJIGxlYW4gdG93YXJkcyB0aGlua2luZyBleHBsaWNpdCBpcyB1c3VhbGx5 IGJldHRlci4gSSBjYW4gc2VlIHNvbWUgdXNlcyBmb3IgaW1wbGljaXQsIGZvciBleGFtcGxlIGlm IGFuIElQIGFkZHJlc3MgaXMgb2JzY3VyZWQgYnkgYSBOQVQsIGEgbm9kZSBtaWdodCBub3QgYmUg YWJsZSB0byBleHBsaWNpdGx5IGluZGljYXRlIGl0cyBJUCBhZGRyZXNzIHRvIGEgcGVlci4gQnV0 IHRoYXQgd291bGQgYmUgbW9yZSBvZiBhbiBleHBsaWNpdCBzY29wZSBpbmRpY2F0aW9uIHdpdGgg YW4gaW1wbGljaXQgdmFsdWUuIEZvciBleGFtcGxlIGEgSG9zdCBzY29wZSB3aXRoIGEgdmFsdWUg b2YgIndoYXRldmVyIElQIGFkZHJlc3MgeW91IHJlY2VpdmVkIHRoaXMgcmVxdWVzdCBmcm9tIg0K Pj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBUaGUgIndoYXRldmVyIElQIHlvdSByZWNlaXZlZCB0 aGlzIHJlcXVlc3QgZnJvbSIgY29uY2VwdCBjb3VsZCBiZSB1c2VmdWwgZm9yIHNvbWUgb3RoZXIg c2NvcGVzIGFsc28uICBGb3IgZXhhbXBsZSwgd2hhdGV2ZXIgY29ubmVjdGlvbiB5b3UgcmVjZWl2 ZWQgdGhpcyByZXF1ZXN0IG9uLCBvciB3aGF0ZXZlciBhcHBsaWNhdGlvbiB5b3UgcmVjZWl2ZWQg dGhpcyByZXF1ZXN0IG9uLg0KPj4+Pj4gDQo+Pj4+PiBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYW55 IG90aGVyIHdheSB0byBkbyAiY29ubmVjdGlvbiIgdG8gbWVhbiBhbnl0aGluZyBidXQgInRoaXMg Y29ubmVjdGlvbiIuIEkgZ3Vlc3Mgd2UgY291bGQgZXhwbGljaXRseSBuYW1lIGEgNS10dXBsZSwg YnV0IEkgc3VzcGVjdCB0aGF0IHdheSBsZWFkcyB0byBtYWRuZXNzLiBPVE9ILCAidGhpcyBhcHBs aWNhdGlvbiIgY291bGQganVzdCBhcyBlYXNpbHkgYmUgbmFtZWQgZXhwbGljaXRseSwgc28gSSdt IG5vdCBzdXJlIHRoZXJlJ3MgYSBiZW5lZml0IHRoZXJlLg0KPj4+Pj4gDQo+Pj4+Pj4gSSB3b25k ZXIgaWYgdGhhdCB3b3VsZCBzYXRpc2Z5IHRoZSB1c2UgY2FzZXMgdGhhdCBmb2xrcyBhcmUgdGhp bmtpbmcgb2Ygd2hlbiB0aGV5IGJyaW5nIHVwIGltcGxpY2l0IHNjb3Blcz8NCj4+Pj4+IA0KPj4+ Pj4gSSBkb24ndCBrbm93IHRoZSBhbnN3ZXIgdGhlcmUtLXRoYXQncyB3aHkgSSBhc2tlZCBhIHNp bWlsYXIgcXVlc3Rpb24gaW4gdGhlIHByZXZpb3VzIGVtYWlsIDotKQ0KPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IERpTUUgbWFpbGlu ZyBsaXN0DQo+Pj4+PiBEaU1FQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+PiBEaU1FIG1haWxpbmcgbGlzdA0KPj4+Pj4gRGlNRUBp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l DQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+PiBEaU1FIG1haWxpbmcgbGlzdA0KPj4+PiBEaU1FQGlldGYub3JnDQo+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPj4+IA0KPj4+IA0KPj4g DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZQ0K From jouni.nospam@gmail.com Wed Jul 24 06:53: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 CF01611E8151 for ; Wed, 24 Jul 2013 06:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm2XVBfy0+31 for ; Wed, 24 Jul 2013 06:53:02 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFA21F867B for ; Wed, 24 Jul 2013 06:52:43 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg1so189591bkc.34 for ; Wed, 24 Jul 2013 06:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=347QnJ2TFXtTtsw78SIXQAteXziq9PeKUDWrsMI8Mdg=; b=SxlaoK3RlgFdBY93mGaIDPVlCaCCfN5m3m059/8jsaenyuIq1SRAOENzpYJ3MnER1i N1ktVQ21WSOG/AvmgQf9Ex933OF0EvSUcN/1BYOVZ3etISM+DmrVixH9d0tFr79Zomlo piJ2XvvThR0qsJOmb8+3U550jZWvvn4BLBzf39UTkK3FYJ0CiT23hmVt0iXNguLiADha mNK0NLo5V56lPoOFzoJfpJfW/QitHmRNElQfPdTLn0JU80HQ/TIvwvWD5IlnBtYt6Vyv I9QuLV4XVR4sPSNV7QzOL7uOJIGWfaioebwLsK+5RZPDk2EThU3K5nyjUYiLPutEh7Xh WytA== X-Received: by 10.204.188.200 with SMTP id db8mr5357597bkb.12.1374673949901; Wed, 24 Jul 2013 06:52:29 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:48cf:a62d:d740:cb1d? ([2001:1bc8:101:f101:48cf:a62d:d740:cb1d]) by mx.google.com with ESMTPSA id qw6sm9680259bkb.4.2013.07.24.06.52.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 06:52:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 24 Jul 2013 16:52:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <12F9A81A-2EDF-46F4-B92D-FC91F34348CC@gmail.com> References: <51EF1A3D.802@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-tschofenig-dime-overload-arch-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:53:07 -0000 With respect to _all_ proposals there is also draft-korhonen-dime-ovl-01 = ;-) - jouni On Jul 24, 2013, at 5:11 AM, Ben Campbell wrote: > Hi Alan, >=20 > At risk of this being a big thing to ask--could you also take a look = at draft-roach-dime-overload-ctrl-03? It would be useful to have your = opinion on all the current Diameter overload control proposals. >=20 > draft-ietf-dime-overload-reqs-09 might also be useful for context on = the discussion so far. >=20 > Thanks! >=20 > Ben. >=20 > On Jul 23, 2013, at 7:05 PM, Alan DeKok = wrote: >=20 >> Hannes asked me to review the documents. While I've been avoiding >> Diameter, many of the principles are similar across AAA protocols. >>=20 >> Over all the document seems reasonable, and describes a consistent >> architecture. >>=20 >> My biggest issue is Section 4.3, the "Exchange of Load Info" >> discussion. I have some concerns here. >>=20 >> Such signaling doesn't work well across proxies. i.e. For the = diagram >> in Section 4.3, the Diameter servers can signal load information to = the >> load balancer. However, the load balancer does not signal load >> information to clients. >>=20 >> Even if the load balancer did signal load to the client, what does it >> signal? It has to aggregate load information across all Diameter >> servers. It's not clear how that would be done. >>=20 >>=20 >> I discussed a potentially better system with Hannes earlier today. >> The idea is essentially a single queue, multiple-server method. It's >> similar to that used in some stores: >>=20 >> http://puzzlor.editme.com/queue >> = http://www.ask.com/answers/39346021/why-a-single-queue-with-multiple-serve= rs-performs-better-than-each-server-having-their-own-queue >>=20 >> The method requires no feedback from the server to the load balancer. >> The load balancer simply monitors requests and responses. The >> algorithm can be implemented by a load balancer, or a client which = has >> multiple home servers. >>=20 >> The idea (in short) is to keep track of a number C, which is the = count >> of requests sent to a home server which have not yet seen a response. >> The goal is to keep C the same across all N home servers in a load >> balance pool. >>=20 >> When a new request comes in, the load balancer chooses a home server = H >> with the lowest C value, and increments C. If there are multiple = home >> servers with the same lowest C value, one is chosen at random. >>=20 >> The result is that servers require no additional signaling to the = load >> balancer. Offered load is spread evenly across home servers of equal >> responsiveness. Where one home server accepts more load than the >> others, it is sent more offered load. >>=20 >>=20 >> The rest of the document involves signaling of overload information. >> Signaling overload is more useful than signaling load-balance >> information. However, I think statements like the following in 5.2.3 >> are inflexible: >>=20 >> INCREASING_OVERLOAD 1 The Diameter server uses this value >> to inform the client that overload has increased and that the >> Diameter client shall decrease the sending rate into half >> (calculated over the last 10 minutes). >>=20 >> Why would the sending rate decrease by half? Why not any other = value? >>=20 >> It may be better for the Diameter server to simply respond with a >> message saying "I'm busy. Retry this request in N seconds". That >> message solves two purposes. One, it signals overload, which is a = good >> thing. Two, it allows the server to selectively control the clients >> back-off method. >>=20 >> Experience shows that making decisions in the server is simpler and >> more flexible than making decisions in the client. The only issue I = see >> here is that this signaling would have to be in-band. >>=20 >> i.e. a Diameter client sends a request X, and instead of receiving a >> normal reply, it receives an error reply indicating the = re-transmission >> timer. This may be fit in with the current diameter practice. I'm = not >> familiar enough to say for sure. >>=20 >>=20 >> The algorithm for the load-balancing solution is simple. It's been >> implemented in at least one AAA server for a decade, with no known = issues. >>=20 >> The algorithm for retransmission signaling is less obvious. Both the >> information to be tracked, and the algorithm are unknown. >>=20 >> I believe that these approaches would be simpler and more robust than >> alternatives. >>=20 >> I'll spend some time modeling various algorithms for the >> retransmission signaling. The solution seems simple to me, but is = also >> not obvious right now. >>=20 >> Alan DeKok. >> _______________________________________________ >> 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 lionel.morand@orange.com Wed Jul 24 07:04:40 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 00A3E11E80CC for ; Wed, 24 Jul 2013 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt2DmCjksr4L for ; Wed, 24 Jul 2013 07:04:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BEAB211E80E8 for ; Wed, 24 Jul 2013 07:04:31 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D2902264F99; Wed, 24 Jul 2013 16:04:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ABB5923804B; Wed, 24 Jul 2013 16:04:25 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 16:04:25 +0200 From: To: Benoit Claise , dime mailing list Thread-Topic: [Dime] AD review of draft-ietf-dime-realm-based-redirect Thread-Index: AQHOh/apk2WMLJSrAk6eaihY/IvfFplzk1WQ Date: Wed, 24 Jul 2013 14:04:24 +0000 Message-ID: <19162_1374674665_51EFDEE9_19162_49_1_6B7134B31289DC4FAF731D844122B36E231E29@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <51EE7BBE.1050804@cisco.com> <51EF07E5.7070300@cisco.com> In-Reply-To: <51EF07E5.7070300@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E231E29PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [Dime] AD review of draft-ietf-dime-realm-based-redirect 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, 24 Jul 2013 14:04:40 -0000 --_000_6B7134B31289DC4FAF731D844122B36E231E29PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit, please see below. Regards, Lionel (as Doc Shepherd) De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben= oit Claise Envoy=E9 : mercredi 24 juillet 2013 00:47 =C0 : dime mailing list Objet : [Dime] AD review of draft-ietf-dime-realm-based-redirect Dear authors, Here is my AD review. If some points have been discussed on the mailing list, don't hesitate to l= et me know. 1. The following sentence contains twice "but instead" The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent, but instead must be performed by a redirect agent as defined in [RFC6733], but instead by an applica= tion-aware Diameter node (Diameter server or proxy). Don't you mean? The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent [RFC6733], but instead by an applica= tion-aware Diameter node (Diameter server or proxy). [LM] OK. 2. Because realm-based redirection is not part of the Diameter base protocol [RFC6733], support of realm= -based redirection by a Redirect agent MUST be specified as part of functionality supported by a Diameter application. This contradicts the following sentence The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent [RFC6733], but instead by an applica= tion-aware Diameter node (Diameter server or proxy). Do I understand correctly that the justification is that, citing RFC 6733, = Redirect Agents can't inspect the application. "Diameter relays and redirect agents are transparent to the Diameter applications, but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications." I could understand all this if "by a Redirect Agent" would be removed in th= e first paragraph. OLD: Because realm-based redirection is not part of the Diameter base protocol [RFC6733], support of realm= -based redirection by a Redirect agent MUST be specified as part of functionality supported by a Diameter application. NEW: Because realm-based redirection is not part of the Diameter base protocol [RFC6733], support of realm= -based redirection MUST be specified as part of functionality supported by a Diameter application. [LM] Correct But then, if it doesn't apply to a Redirect Agent, then why do we have this= paragraph However, despite the change in executing role, the behaviour itself is a slight modification of the behaviour of a redirect agent as described in Section 2.8.3 of [RFC6733]. [LM]My understanding is to point out that the role of the Realm-based redir= ect proxy/server is very close to the behavior of a "regular" redirect agen= t, and therefore most of what applies for Redirect agent apply to the Realm= -based redirect proxy/server. 3. An application can specify that realm-based redirection operates only on the initial message of a session, or on any message of a session. "only the initial message" or "on any message of a session" =3D "on any mes= sage of a session", right? Remove "only", that would make sense with the next sentence in the paragrap= h. [LM] would it be: "operates either only on the initial message of a session= , or on any message of a session" Same remark for the first paragraph in 3.2.1 4. I thought about this use case: "consider the case where an operator has offered a specific service but no longer wishes to do so. The operator has arranged for an alternative domain to provide the service." Don't we need "Redirect-Max-Cache-Time" =3D "forever"? Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is not p= resent? I could not find a definitive answer in the draft or in RFC 6733 [LM] A redirection is always a "temporary" info so the Max-Cache-Time is a= lways present when a cache is created. The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. This AVP MUST be present in answer messages whose 'E' bit is set, whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon as y= ou need to cache the info). About the "forever", you can't say more than "keep the info cached for 136 = years". So it is not "forever" but not too bad. 5. If the redirected request contained a Destination-Host AVP, that AVP is ignored by the redirecting server. Pay attention that you update RFC 6733 Proposal If the redirected request contains a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, that Destination-Host AVP MUST be ignored by the redirecting server. Or When a directed request contains a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP content MUST be ignored by the redirecting server. [LM] I think that "redirected" is misleading here as "redirected request" i= s used as "the request to be redirected". The clarification here is about the fact that as per RFC6733, a request con= taining a Destination-Host cannot be rerouted: An example of a case where it is not possible to forward the message to an alternate server is when the message has a fixed destination, and the unavailable peer is the message's final destination (see Destination-Host AVP). Such an error requires that the agent return an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. About ignoring the Destination-Host, I think that it is not possible to say= "MUST be ignored" as it will be application-dependent. For instance, one c= riterion for realm based redirection can be: "only for initial session requ= est when no Destination-host is present". We could say: "The Realm-based re= direction MAY be applied even if a Destination-Host AVP is present in the r= equest, depending on the operator-based policy." 6. A proxy conforming to this specification that receives an answer message with the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the original request to a server in a realm identified by a Redirect- Realm AVP instance in the answer message, or MAY simply forward the message toward the client. It MUST do one of the two things, I guess. Otherwise, doing nothing is also= a valid option according to the text. Please mention it. [LM] Any proxy can do something but a proxy conforming to this specificatio= n MUST attempt to reroute... and if it fails, MUST forward the indication t= o the client. 7. Section 3.2.2 And what if all point of the procedure fail, for all realms, what should ha= ppen? DIAMETER_REDIRECT_INDICATION to the client? [LM] yes. See above. Editorial - Redirect agent versus redirect agent - Redirecting Server is a new term AFAICT, and is not really defined (even = if we can guess). Is this intentional? [LM] should be introduced in the def section. Regards, Benoit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E231E29PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 = ;

please see= below.

 = ;

Regards,

 = ;

Lionel (as= Doc Shepherd)

 = ;

De := dime-bounces@ietf.org [mailto:dime-bounces@ie= tf.org] De la part de Benoit Claise
Envoy=E9 : mercredi 24 juillet 2013 00:47
=C0 : dime mailing list
Objet : [Dime] AD review of draft-ietf-dime-realm-based-redirec= t

 

Dear authors,
 
Here is my AD review.
If some points have been discussed on the mailing list, don't hesitate=
 to let me know.
 
 
1.
The following sentence contains twice "but instead"
 
   The result of making realm-based redirection an applicati=
on-specific
   behaviour is that it cannot be performed by a redirect ag=
ent, but
   instead must be performed by a redirect agent as defined =
in
   [RFC6733], but instead by an applica=
tion-aware Diameter node
   (Diameter server or proxy). 
 
Don't you mean?
 
   The result of making realm-based redirection an applicati=
on-specific
   behaviour is that it cannot be performed by a redirect ag=
ent 
   [RFC6733], but instead by an ap=
plication-aware Diameter node
   (Diameter server or proxy). 
[LM] OK.
 
 
2.
 
   Because realm-based redirection is not part of the Diamet=
er base
   protocol [RFC6733], support of realm=
-based redirection by a Redirect
   agent MUST be specified as part of functionality s=
upported by a
   Diameter application.
   
This contradicts the following sentence
  
   The result of making realm-based redirection an appl=
ication-specific
   behaviour is that it cannot be performed by a redirect=
 agent 
   [RFC6733], but instead by an ap=
plication-aware Diameter node
   (Diameter server or proxy).
 
Do I understand correctly that the justification is that, citing RFC 6=
733, Redirect Agents can't inspect the application.
   "Diameter relays and redirect agents are transparent=
 to the Diameter
   applications, but they MUST support the Diameter base pro=
tocol, which
   includes accounting, and all Diameter applications."=
 
 
I could understand all this if "by a Redirect Agent" would b=
e removed in the first paragraph.
OLD:
   Because realm-based redirection is not part of the Diamet=
er base
   protocol [RFC6733], support of realm=
-based redirection by a Redirect
   agent MUST be specified as part of functionality supporte=
d by a
   Diameter application.
 
NEW:
   Because realm-based redirection is not part of the Diamet=
er base
   protocol [RFC6733], support of realm=
-based redirection MUST be 
   specified as part of functionality supported by a Di=
ameter application.
[LM] Correct
 
But then, if it doesn't apply to a Redirect Agent, then why do we have=
 this paragraph
   However, despite the change in executing
   role, the behaviour itself is a slight modification of th=
e behaviour
   of a redirect agent as described in Section 2.8.3 of [RFC6733]=
. 
[LM]My understanding i=
s to point out that the role of the Realm-based redirect proxy/server is ve=
ry close to the behavior of a "regular" redirect agent, and there=
fore most of what applies for Redirect agent apply to the Realm-based redir=
ect proxy/server.<=
o:p>
 
3.
   An application can specify that realm-based redirection o=
perates only
   on the initial message of a session, or on any message of=
 a session.
 
"only the initial message" or "on any message of a sess=
ion" =3D "on any message of a session", right?

Remove "only", that would make sense with the next sentence =
in the paragraph.


[LM] would it be: "operates either only on the initial m=
essage of a session, or on any message of a session"


 

Same remark for the first paragraph in 3.2.1=



 


4.


I thought about this use case:


   "consider the case where an operator has offered a s=
pecific


   service but no longer wishes to do so.  The operator=
 has arranged for


   an alternative domain to provide the service."<=
/o:p>


Don't we need "Redirect-Max-Cache-Time"=
 =3D "forever"?


Unless ... "forever" is meant when the Redirect-Max-Cache-Ti=
me AVP is not present?


I could not find a definitive answer in the draft or in RFC 6733 =



[LM] A redirection is =
always  a "temporary" info so the Max-Cache-Time is always p=
resent when a cache is created.


   The Redirect-Max-Cache-Time AVP (AVP=
 Code 262) is of type Unsigned32.


   This AVP MUST be present in a=
nswer messages whose 'E' bit is set,


   whose Result-Code AVP is set to DIAM=
ETER_REDIRECT_INDICATION, and


   whose Redirect-Host-Usage AVP set to=
 a non-zero value (i.e. as soon as you need to cache the info).<=
/span>


About the "foreve=
r", you can't say more than "keep the info cached for 136 years&q=
uot;. So it is not "forever" but not too bad.


 


5.


      If the redirected request contained a D=
estination-Host AVP, that


      AVP is ignored by the redirecting serve=
r.


 


Pay attention that you update RFC 6733


 


Proposal


      If the redirected request contains a Re=
sult-Code AVP set to


      DIAMETER_REALM_REDIRECT_INDICATION and =
a Destination-Host AVP, 


      that Destination-Host AVP MUST be =
ignored by the redirecting server.


 


Or 


      When a directed request contains a=
 Result-Code AVP set to


      DIAMETER_REALM_REDIRECT_INDICATION, the=
 Destination-Host AVP


      content MUST be ignored by the redirecting s=
erver.


[LM] I think that &quo=
t;redirected" is misleading here as "redirected request" is =
used as "the request to be redirected".=



The clarification here=
 is about the fact that as per RFC6733, a request containing a Destination-=
Host cannot be rerouted:


   An example of=
 a case where it is not possible to


   forward the m=
essage to an alternate server is when the message has a

   fixed destina=
tion, and the unavailable peer is the message's final


   destination (=
see Destination-Host AVP).  Such an error requires that


   the agent ret=
urn an answer message with the 'E' bit set and the


   Result-Code A=
VP set to DIAMETER_UNABLE_TO_DELIVER.


 


About ignoring the Des=
tination-Host, I think that it is not possible to say "MUST be ignored=
" as it will be application-dependent. For instance, one criterion for=
 realm based redirection can be: "only for initial session request whe=
n no Destination-host is present". We could say: "The Realm-based=
 redirection MAY be applied even if a Destination-Host AVP is present in th=
e request, depending on the operator-based policy."


 


6.


   A proxy conforming to this specification that receives an=
 answer


   message with the Result-Code AVP set to


   DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute=
 the


   original request to a server in a realm identified by a R=
edirect-


   Realm AVP instance in the answer message, or MAY simply f=
orward the


   message toward the client. 


 


It MUST do one of the two things, I guess. Otherwise, doing nothing is=
 also a valid option according to the text.


Please mention it.


[LM] Any proxy can do =
something but a proxy conforming to this specification MUST attempt to rero=
ute… and if it fails, MUST forward the indication to the client.


 


 


7.


Section 3.2.2


And what if all point of the procedure fail, for all realms, what shou=
ld happen?


DIAMETER_REDIRECT_INDICATION to the client?


[LM] yes. See above.


 


 


Editorial


- Redirect agent versus redirect agent


- Redirecting Server is a new term AFAICT, and is not really defined (=
even if we can guess).


Is this intentional?


[LM] should be introdu=
ced in the def section.


 


 


Regards, Benoit


 

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E231E29PEXCVZYM13corpora_-- From ben@nostrum.com Wed Jul 24 07:09: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 ECB6711E8104 for ; Wed, 24 Jul 2013 07:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhVwXkH1COWh for ; Wed, 24 Jul 2013 07:09:09 -0700 (PDT) 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 ED11F11E80CC for ; Wed, 24 Jul 2013 07:09:08 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6OE8BFQ058847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2013 09:08:11 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <12F9A81A-2EDF-46F4-B92D-FC91F34348CC@gmail.com> Date: Wed, 24 Jul 2013 09:08:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5BEE3F46-8B71-49FD-9962-551AA47E1807@nostrum.com> References: <51EF1A3D.802@deployingradius.com> <12F9A81A-2EDF-46F4-B92D-FC91F34348CC@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-tschofenig-dime-overload-arch-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:09:11 -0000 Oops, sorry. I had actually meant my second sentence to expand my = request to cover _all_ the drafts. I clearly did not make that clear :-) Thanks! Ben. On Jul 24, 2013, at 8:52 AM, Jouni Korhonen = wrote: >=20 > With respect to _all_ proposals there is also = draft-korhonen-dime-ovl-01 ;-) >=20 > - jouni >=20 >=20 > On Jul 24, 2013, at 5:11 AM, Ben Campbell wrote: >=20 >> Hi Alan, >>=20 >> At risk of this being a big thing to ask--could you also take a look = at draft-roach-dime-overload-ctrl-03? It would be useful to have your = opinion on all the current Diameter overload control proposals. >>=20 >> draft-ietf-dime-overload-reqs-09 might also be useful for context on = the discussion so far. >>=20 >> Thanks! >>=20 >> Ben. From aland@deployingradius.com Wed Jul 24 07:12:52 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 DDB7C11E80AE for ; Wed, 24 Jul 2013 07:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqxlBhXGqDGf for ; Wed, 24 Jul 2013 07:12:45 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEDE11E8133 for ; Wed, 24 Jul 2013 07:12:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 55C6E22400C8; Wed, 24 Jul 2013 16:11:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XRkma2WVU0v; Wed, 24 Jul 2013 16:11:40 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 3F483224006E; Wed, 24 Jul 2013 16:11:40 +0200 (CEST) Message-ID: <51EFE09E.90102@deployingradius.com> Date: Wed, 24 Jul 2013 10:11:42 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ben Campbell References: <51EF1A3D.802@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-roach-dime-overload-ctrl-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: Wed, 24 Jul 2013 14:12:52 -0000 Ben Campbell wrote: > At risk of this being a big thing to ask--could you also take a look at draft-roach-dime-overload-ctrl-03? It would be useful to have your opinion on all the current Diameter overload control proposals. Here's my initial impression. I hope it's clear. ... The inclusion of load and overload information in existing messages has the property that the frequency with which information can be exchanged increases as load on the system goes up. I would hazard a guess and say that for 99% of the messages between nodes A and B, the load information is relatively static. i.e. it changes slowly over time. This means that "always-on" signing is efficient. In the grand scheme of things, it's probably not too much to worry about. Networks are fast and getting faster. So adding a bit more to each message isn't serious. Adding *periodic* load information to messages would fulfill the same goal. Section 2 - Overload scopes To me, in-band signaling like this is a problem. The issue seems to be that we require a AAA routing protocol. That protocol would signal whether realm A was reachable, and if so, what path(s) could be used to reach it. Describing it as a routing protocol seems better to me. As seen by this comment in Section 3: OPEN ISSUE: SIP Overload Control includes a sequence parameter to ensure that out-of-order messages do not cause the receiver to act on state that is no longer accurate. A routing protocol would ensure that state changes are propogated smoothly through the network, without out-of-order issues. It may use a sequence number, but dealing with order would be an explicit design goal of the protocol. ... To implement overload control, Diameter nodes need to keep track of three important metrics for each of the scopes for which information has been received: the overload metric for the scope, ... This is the first introduction of "overload metric". What is it? What does it mean? ... In order to allow recipients of overload information to perform certain performance optimizations, we also define a new command flag, called 'O'verload. This bit, when set, indicates that the message contains at least one Load-Info AVP with a non-zero Overload-Metric -- in other words, the sending node is overloaded for at least one context. See Section 7.4 for the definition of the 'O'verload bit. What does the overload bit *mean*? The sending node is overloaded. Ok... what does the client *do* with that information? There should be a sentence here introducing the idea that the client does something with the data. Later, we have an explanation: If one or more matching scope entries are in overload, then the sending node determines which scope is most overloaded. The sending node then sends, drops, or otherwise modifies handling of the request according to the negotiated overload control algorithm, using the Overload-Metric from the selected scope entry as input to the algorithm. That covers the missing information from above. When determining which requests are impacted by the overload control algorithm, request senders MAY take into account the type of message being sent and its contents. For example, messages within an existing session may be prioritized over those that create a new session. The exact rules for such prioritization will likely vary from application to application. This worries me. A lot. Let me explain. Having multiple algorithms increases system complexity. Having a *client* implement algorithms is even more problematic. Maybe Diameter is different, but my experience with RADIUS shows that it's best to assume clients are the dumbest things around. Keeping the complexity in the server means that there are fewer places in the network which need this complexity. Servers already have a lot of complexity to deal with various policies, so adding more isn't too difficult. My experience is that it's better to define *actions* for clients, instead of *states* and algorithms. i.e. "come back in 5 seconds" is simpler for a client than "server is in state X, please implement algorithm Y". It means that the server can implement *any* algorithm, and all clients will support it. We only require the "overload" signaling to include the standard network parameters related to time and bandwidth. - send no more than X messages / s - retransmit this message in X seconds - etc. So the server can run the algorithm, and inform the client as to it's expected behavior. No negotiation is required. The client just has to signal it's capability to understand the time / bandwidth messages. It's simpler, easier to understand, easier to implement, and likely to be more flexible and robust. The rest of the document describes such signaling. But calling it "Overload" confuses the issue (IMHO). Maybe it could be "messaging QoS", or something similar. The idea is that it's *normal* to signal changing circumstances between peers. It's not an exceptional or "overload" situation. e.g. Say I want to switch traffic from server A to server B. To do it gradually, I make server A signal that it has gradually lower throughput over time, and server B signals it has gradually higher throughput over time. The end result is that the traffic moves from A to B without any sudden "spikes". The alternative would be to suddenly signal that server A is down, and all of the clients have to suddenly deal with the loss of a server. Section 3.5 Load Processing While the remainder of the mechanism described in this document is aimed at handling overload situations once they occur, it is far better for a system if overload can be avoided altogether. In order to facilitate overload avoidance, the overload mechanism includes the ability to convey node load information. I agree here. I think this document doesn't go far enough. As I said above, load signaling is *normal*. Overload is just a signal that accepted load is approaching zero. I suggest revamping the document to treat load changes as normal, rather than as exceptional. It would make it clearer (to me, at least) what the goal is: managing traffic. Instead of managing exceptional circumstances. 3.5.1. Sending Load Information As noted earlier, I have objections to this approach. Signaling load information is confusing to me. e.g. "OK, the server is overloaded... what do I *do* now?" It should be something like "Signaling Connection Parameters" or "Signaling Requested Sending Behavior". That is an *active* statement. "Signaling Load Information" is a *passive* statement. It doesn't lead the reader to believe he needs to *do* anything with the information. ... The client then examines the currently reported loads for each of the three servers. In this example, we are asserting that the reported load metrics are as follows: This section is a bit opaque to me. It's not clear *why* these calculations are being done. I presume it's taking a convolution of the suggested load distribution with the servers current load. But it's not clear. ... A Diameter node entering the overload state for any of the scopes that it uses with its peers will calculate a value for its Overload Metric, in the range of 0 to 100 (inclusive). This value indicates the percentage traffic reduction the Diameter node wishes its peers to implement. This is good. I would prefer that the earlier parts of the document explain the method. i.e. the earlier parts have motivation, but not a short description of how it works. Such explanations serve to motivate the rest of the document, and put it into a conceptual framework. I have concerns with signaling a percentage traffic reduction. What if the server is overloaded, signals a reduction, and the traffic has already lowered? The client would seem to lower it's already lowered traffic. The client then sends less traffic than the server can accept. It would be better to signal throughput instead. i.e. "limit throughput to X messages/s". When the traffic on the client lowers, it discovers that it is already compliant with the request. And does nothing. That's my $0.02 for now. Alan DeKok. From jouni.nospam@gmail.com Wed Jul 24 12:26:22 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 7798411E8144 for ; Wed, 24 Jul 2013 12:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ele3NbfgqrL for ; Wed, 24 Jul 2013 12:26:11 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5F78311E812A for ; Wed, 24 Jul 2013 12:26:02 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk13so341018bkc.15 for ; Wed, 24 Jul 2013 12:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=2Vz8QOXMmgwPn3bZHkpjmVU1hinqQnGdJyHQciMCYSc=; b=AAXASGIPKHY0ID1SFy73Wgk29xuwsZ3CVlBz8/c3/MSWXPgqpjgAWH8j2wtaWgacvF XZy8kS4j0m1EKR9iTkfMy4/cBV5IJxGLxpUDHc1VDCthjzEtjsv9iUtcCRWOUB8m79Km dFKh/WKZZKZOBMwRA45Urhz/+JF2y/cWIBE8SZ0CgVJjQDhdi3nfJF/EhrRVN+5GoxwF FEKrn+3GVI2DzNRehrJI4IUVBZWSdv5/MFgG20QPp6q2wXaOtUX9aXGeevMwEGdX5pvj O50jG8zuBySbPGVXYIjAwUu4+wy9UmgSTTeYWFbfFqRjT1TlZ2NkZPucpZtI0PaqNgsU T83w== X-Received: by 10.205.22.196 with SMTP id qx4mr5496552bkb.156.1374693940169; Wed, 24 Jul 2013 12:25:40 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id qw6sm10009545bkb.4.2013.07.24.12.25.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 12:25:39 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <02A9A2C1-A42F-4AF7-829E-C9377339AAA7@gmail.com> Date: Wed, 24 Jul 2013 22:25:38 +0300 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Dime] IETF87 meeting logistics 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, 24 Jul 2013 19:26:22 -0000 Folks, Two things: 1) If you feel an urge to take meeting notes or do the jabber scribe, feel free to contact the chairs. 2) Those who are on the agenda, please send your slides to the chairs by Thursday 1st Aug 1PM.. - Jouni & Lionel From hannes.tschofenig@gmx.net Wed Jul 24 12:32:40 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 C6EE911E8255 for ; Wed, 24 Jul 2013 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYO5iJwg-DoY for ; Wed, 24 Jul 2013 12:32:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B105F11E819B for ; Wed, 24 Jul 2013 12:32:34 -0700 (PDT) Received: from [172.16.254.103] ([195.149.218.153]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LfXmv-1UIGT00qOP-00p5VS for ; Wed, 24 Jul 2013 21:32:31 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <02A9A2C1-A42F-4AF7-829E-C9377339AAA7@gmail.com> Date: Wed, 24 Jul 2013 21:32:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5442FEDB-3441-47FA-AFDB-FCBF6EE7531B@gmx.net> References: <02A9A2C1-A42F-4AF7-829E-C9377339AAA7@gmail.com> To: Jouni Korhonen X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:zrZCO84MvYOPz1nKl69v8lxwTdlNFFho6TxbgUm+rcIn33nguin zcBlLbEp4aVNy6mP+SE9+p7IsoYDdI/D5I2YIPTokygR/DmVyeWh1ZntW8ezqUgsmWzx1Uk Q+EyBzUdzcDzxYeR2he+9rCWQ40szTmAVlYVhSxf7WUCvOGV1gYmAyYohr4OCugrSUlIOLZ DWK+2D/9bDlVgfs9KRdRA== Cc: "dime@ietf.org" Subject: Re: [Dime] IETF87 meeting logistics 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, 24 Jul 2013 19:32:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I just wanted to say that it would be important to have a Jabber scribe = since Alan plans to participate from remote since he is interested to = follow the Diameter overload discussions (after I had a chat with him = about his experience in the RADIUS space).=20 Ciao Hannes On Jul 24, 2013, at 9:25 PM, Jouni Korhonen wrote: > Folks, >=20 > Two things: >=20 > 1) If you feel an urge to take meeting notes or do the jabber scribe, > feel free to contact the chairs. >=20 > 2) Those who are on the agenda, please send your slides to the chairs > by Thursday 1st Aug 1PM.. >=20 >=20 > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR8CvOAAoJEGhJURNOOiAt+9oIAJPnO78pFYwxLZbaPflDjnqY iFuOyssRQ8vI6w6og8miXaH6hz2KUAcxZ+W/mqQ8Fpc//QGaV5Dxnxfuuf9ibpUr LujFgRzeHUStzYU9hWrjdznAQt4wI+OXr7V3XBFG5O4C9cCi1GzARA9SxR0yJ4+j A+vSgs9WY/YvgPHiajA5VLY37ibQ1Dc33r4INKej5HrZXgc9rFkV+60qA3kLB1A/ jc7W/UgMoNM2yDG3Ue4mlrMI6olfyfXnXz5TaSYg9PkNx8BuuWjI05f5l3h0TUsN hBiVFh2tWawVj3h+3DHBNSkhhBxXH5lF4fr6tft98Bh7ZdvObLDSLJ0MMW4E7yU=3D =3DrcQz -----END PGP SIGNATURE----- From mahoney@nostrum.com Wed Jul 24 12:42:03 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 11DFE11E8144 for ; Wed, 24 Jul 2013 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwntW1DUWEaB for ; Wed, 24 Jul 2013 12:42:02 -0700 (PDT) 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 0C1CB11E8105 for ; Wed, 24 Jul 2013 12:42:01 -0700 (PDT) Received: from A-Jean-Mahoneys-MacBook-Pro.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6OJg0ns097008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Jul 2013 14:42:00 -0500 (CDT) (envelope-from mahoney@nostrum.com) Message-ID: <51F02E03.6040603@nostrum.com> Date: Wed, 24 Jul 2013 14:41:55 -0500 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dime@ietf.org References: <02A9A2C1-A42F-4AF7-829E-C9377339AAA7@gmail.com> In-Reply-To: <02A9A2C1-A42F-4AF7-829E-C9377339AAA7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [Dime] IETF87 meeting logistics 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, 24 Jul 2013 19:42:03 -0000 I'll take meeting minutes. Jean On 7/24/13 2:25 PM, Jouni Korhonen wrote: > Folks, > > Two things: > > 1) If you feel an urge to take meeting notes or do the jabber scribe, > feel free to contact the chairs. > > 2) Those who are on the agenda, please send your slides to the chairs > by Thursday 1st Aug 1PM.. > > > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From tom.taylor.stds@gmail.com Wed Jul 24 13:55:09 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 B356911E8240 for ; Wed, 24 Jul 2013 13:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6IROfHbm2hB for ; Wed, 24 Jul 2013 13:55:07 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5B00A11E8137 for ; Wed, 24 Jul 2013 13:55:04 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so2229859oag.4 for ; Wed, 24 Jul 2013 13:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bSCgVYzTUYem8L6UKjysJNYo3uSVI66FZ3do2xPfNZI=; b=teZWvtqLiMJxHMJNTua0SSjM/LQWuwzBTFeQCNa+AkOOthT3WLrqs/Q7X3a3uePy9o nzAAWvLzaJdSTgwqRGWGrKP6zAYSOoZNYT9LSIXzE6VKmwpsRJ2JETX3LLPFILI7Uh+P F+gJJgfTWLUVGP6PvlwwO/6Lq5Nk0XtsxPlQYjWvgl0418XOq/Pp3f3d7+c8+I9mLBP2 AeRw229kMqiHqyrXSWiTyrrpYD4XRoO0ZnbYEQt8g/KSK6T88/TuvxtKqV+gWL4IKOci +Jkas+7j3oPFXTbx+RGagmRAcVVGwH2pBotWYUV5QlDMYJGDlIh/kp+x525OkCJF5bv6 k7xg== X-Received: by 10.182.72.170 with SMTP id e10mr32910024obv.62.1374699304225; Wed, 24 Jul 2013 13:55:04 -0700 (PDT) Received: from [192.168.1.64] (dsl-173-206-92-228.tor.primus.ca. [173.206.92.228]) by mx.google.com with ESMTPSA id tu4sm44303228obb.5.2013.07.24.13.54.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:55:03 -0700 (PDT) Message-ID: <51F03F1B.1010702@gmail.com> Date: Wed, 24 Jul 2013 16:54:51 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lionel.morand@orange.com References: <51EE7BBE.1050804@cisco.com> <51EF07E5.7070300@cisco.com> <19162_1374674665_51EFDEE9_19162_49_1_6B7134B31289DC4FAF731D844122B36E231E29@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19162_1374674665_51EFDEE9_19162_49_1_6B7134B31289DC4FAF731D844122B36E231E29@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime mailing list Subject: Re: [Dime] AD review of draft-ietf-dime-realm-based-redirect 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, 24 Jul 2013 20:55:09 -0000 Thanks for picking this up, Lionel. I started to work on a response last night but got distracted by other work. Comments below marked with [PTT]. Parts where I have nothing to add to Lionel's responses are omitted. Tom Taylor On 24/07/2013 10:04 AM, lionel.morand@orange.com wrote: > Hi Benoit, > > please see below. > > Regards, > > Lionel (as Doc Shepherd) > ... > > But then, if it doesn't apply to a Redirect Agent, then why do we > have this paragraph > > However, despite the change in executing > > role, the behaviour itself is a slight modification of the behaviour > > of a redirect agent as described in Section 2.8.3 of > [RFC6733]. > > [LM]My understanding is to point out that the role of the Realm-based > redirect proxy/server is very close to the behavior of a "regular" > redirect agent, and therefore most of what applies for Redirect agent > apply to the Realm-based redirect proxy/server. > [PTT] Agreed. The purpose of this text is just to give the reader a point of reference for what follows. > > > 3. > > An application can specify that realm-based redirection operates > only > > on the initial message of a session, or on any message of a session. > > > > "only the initial message" or "on any message of a session" = "on any > message of a session", right? > > Remove "only", that would make sense with the next sentence in the > paragraph. > > [LM] would it be: "operates either only on the initial message of a > session, or on any message of a session" > > > > Same remark for the first paragraph in 3.2.1 > [PTT] I think what I mean to say in Section 2 is: "only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated." Then in Section 3.1.2 I would repeat the first sentence. > > > 4. > > I thought about this use case: > > "consider the case where an operator has offered a specific > > service but no longer wishes to do so. The operator has arranged > for > > an alternative domain to provide the service." > > Don't we need "Redirect-Max-Cache-Time" = "forever"? > > Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is > not present? > > I could not find a definitive answer in the draft or in RFC 6733 > > [LM] A redirection is always a "temporary" info so the > Max-Cache-Time is always present when a cache is created. > > The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type > Unsigned32. > > This AVP MUST be present in answer messages whose 'E' bit is set, > > whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and > > whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon > as you need to cache the info). > > About the "forever", you can't say more than "keep the info cached > for 136 years". So it is not "forever" but not too bad. > > [PTT] No action here? > > 5. > > If the redirected request contained a Destination-Host AVP, that > > AVP is ignored by the redirecting server. > > > > Pay attention that you update RFC 6733 > > > > Proposal > > If the redirected request contains a Result-Code AVP set to > > DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, > > that Destination-Host AVP MUST be ignored by the redirecting server. > > > > Or > > When a directed request contains a Result-Code AVP set to > > DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP > > content MUST be ignored by the redirecting server. > > [LM] I think that "redirected" is misleading here as "redirected > request" is used as "the request to be redirected". > > The clarification here is about the fact that as per RFC6733, a > request containing a Destination-Host cannot be rerouted: An example > of a case where it is not possible to forward the message to an > alternate server is when the message has a fixed destination, and the > unavailable peer is the message's final destination (see > Destination-Host AVP). Such an error requires that the agent return > an answer message with the 'E' bit set and the Result-Code AVP set to > DIAMETER_UNABLE_TO_DELIVER. > > > > About ignoring the Destination-Host, I think that it is not possible > to say "MUST be ignored" as it will be application-dependent. For > instance, one criterion for realm based redirection can be: "only for > initial session request when no Destination-host is present". We > could say: "The Realm-based redirection MAY be applied even if a > Destination-Host AVP is present in the request, depending on the > operator-based policy." > > [PTT] I like that latter formulation. > > 6. > > A proxy conforming to this specification that receives an answer > > message with the Result-Code AVP set to > > DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the > > original request to a server in a realm identified by a Redirect- > > Realm AVP instance in the answer message, or MAY simply forward the > > message toward the client. > > > > It MUST do one of the two things, I guess. Otherwise, doing nothing > is also a valid option according to the text. > > Please mention it. > > [LM] Any proxy can do something but a proxy conforming to this > specification MUST attempt to reroute... and if it fails, MUST > forward the indication to the client. > [PTT] OK, I'll rephrase. > > > > 7. > > Section 3.2.2 > > And what if all point of the procedure fail, for all realms, what > should happen? > > DIAMETER_REDIRECT_INDICATION to the client? > > [LM] yes. See above. > > [PTT] No action? > > > > Editorial > > - Redirect agent versus redirect agent > > - Redirecting Server is a new term AFAICT, and is not really defined > (even if we can guess). > > Is this intentional? > > [LM] should be introduced in the def section. > > [PTT] OK > ... From aland@deployingradius.com Wed Jul 24 18:31:04 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 63F0321F99A6 for ; Wed, 24 Jul 2013 18:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIv7XnwwV9rV for ; Wed, 24 Jul 2013 18:30:56 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC9321F9995 for ; Wed, 24 Jul 2013 18:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 487D022400C8; Thu, 25 Jul 2013 03:30:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugM7i-6rJtIN; Thu, 25 Jul 2013 03:29:59 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 5B16E224009D; Thu, 25 Jul 2013 03:29:59 +0200 (CEST) Message-ID: <51F07F98.8030305@deployingradius.com> Date: Wed, 24 Jul 2013 21:30:00 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <51EF1A3D.802@deployingradius.com> <12F9A81A-2EDF-46F4-B92D-FC91F34348CC@gmail.com> In-Reply-To: <12F9A81A-2EDF-46F4-B92D-FC91F34348CC@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-korhonen-dime-ovl-01 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, 25 Jul 2013 01:31:04 -0000 This is my review of draft-korhonen-dime-ovl-01. It's easier to understand this draft after reviewing the other two. I also find this one clearer. Ideas are presented and motivated before they're discussed in detail. This gives a framework for the later detailed discussion. Over all, the design seems to be more in line with what I've been recommending in my other reviews. As a result, I don't have too many comments. The document doesn't mention load balancing, which would be useful to have. Ideas from the other documents could be applicable. My other reviews contain suggestions for additional (or less) signaling, which also could apply here. - I disagree with the word "overload". Signaling load status should be part of normal behavior, instead of an "overload" condition - load balancing can be done automatically by clients, requiring minimal interaction with servers - servers should send behavior requests to the clients (e.g. throttle traffic to X messages/s) instead of state changes ("I'm overloaded") - signaling realm availability would better be part of a global AAA routing protocol, instead of a hop-by-hop load-balancing protocol Alan DeKok. From emcmurry@computer.org Thu Jul 25 01:24: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 5489F21F999E for ; Thu, 25 Jul 2013 01:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAzWtbWr558O for ; Thu, 25 Jul 2013 01:24:50 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7B421F9339 for ; Thu, 25 Jul 2013 01:24:49 -0700 (PDT) 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 1V2Gqu-000C8N-Jj; Thu, 25 Jul 2013 08:24:48 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id C1C89C96B9E; Thu, 25 Jul 2013 03:24:45 -0500 (CDT) 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: U2FsdGVkX1/su9YNLGEcsk5+6MXKyB/smK5LYOA99KM= 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 DsN3uBHVJMYd; Thu, 25 Jul 2013 03:24:45 -0500 (CDT) Received: from [192.168.13.6] (unknown [192.168.13.6]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 222C8C96B91; Thu, 25 Jul 2013 03:24:42 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <51EFE09E.90102@deployingradius.com> Date: Thu, 25 Jul 2013 10:24:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-roach-dime-overload-ctrl-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: Thu, 25 Jul 2013 08:24:57 -0000 Hi Alan, Thanks for the taking the time to provide comments! discussion inline. Eric On Jul 24, 2013, at 16:11 , Alan DeKok = wrote: > Ben Campbell wrote: >> At risk of this being a big thing to ask--could you also take a look = at draft-roach-dime-overload-ctrl-03? It would be useful to have your = opinion on all the current Diameter overload control proposals. >=20 > Here's my initial impression. I hope it's clear. >=20 > ... > The inclusion of load and > overload information in existing messages has the property that the > frequency with which information can be exchanged increases as load > on the system goes up. >=20 > I would hazard a guess and say that for 99% of the messages between > nodes A and B, the load information is relatively static. i.e. it > changes slowly over time. This means that "always-on" signing is = efficient. >=20 > In the grand scheme of things, it's probably not too much to worry > about. Networks are fast and getting faster. So adding a bit more to > each message isn't serious. >=20 > Adding *periodic* load information to messages would fulfill the same > goal. yes. we've gone back and forth on this a few times. The current = approach is optimized for the receiver so that it can pull out the = information any time it desires, which can be done periodically. This = is just a choice between compute or network resource usage. >=20 > Section 2 - Overload scopes >=20 > To me, in-band signaling like this is a problem. The issue seems to > be that we require a AAA routing protocol. That protocol would signal > whether realm A was reachable, and if so, what path(s) could be used = to > reach it. >=20 > Describing it as a routing protocol seems better to me. As seen by > this comment in Section 3: >=20 > OPEN ISSUE: SIP Overload Control includes a sequence parameter to > ensure that out-of-order messages do not cause the receiver to act = on > state that is no longer accurate. >=20 > A routing protocol would ensure that state changes are propogated > smoothly through the network, without out-of-order issues. It may use = a > sequence number, but dealing with order would be an explicit design = goal > of the protocol. I'm not sure I fully understand this, but I'll take a shot. This note = was pointing out something to think about when there are multiple = connections between peers. The protocol should be fine with this as = overlapped information possible here is on a short enough time scale to = not interact with the critical control information. However, it points = out that some more consideration of this is needed to be sure of that. I understand your point about out of band. That would make sense for = several reasons. However, using the existing protocol is highly = desirable since it is already in place and can support this. >=20 > ... > To implement overload control, Diameter nodes need to keep track of > three important metrics for each of the scopes for which information > has been received: the overload metric for the scope, ... >=20 > This is the first introduction of "overload metric". What is it? = What > does it mean? >=20 It is first mentioned in the overview and there is a section with its = definition. It is the number used by the control algorithm for = deciding/altering it actions. For example, it could be used to request = a percentage of traffic to be dropped when used with a drop algorithm. > ... > In order to allow recipients of overload information to perform > certain performance optimizations, we also define a new command = flag, > called 'O'verload. This bit, when set, indicates that the message > contains at least one Load-Info AVP with a non-zero Overload-Metric > -- in other words, the sending node is overloaded for at least one > context. See Section 7.4 for the definition of the 'O'verload bit. >=20 > What does the overload bit *mean*? The sending node is overloaded. > Ok... what does the client *do* with that information? There should = be > a sentence here introducing the idea that the client does something = with > the data. >=20 > Later, we have an explanation: >=20 > If one or more matching scope entries are in overload, then the > sending node determines which scope is most overloaded. The sending > node then sends, drops, or otherwise modifies handling of the = request > according to the negotiated overload control algorithm, using the > Overload-Metric from the selected scope entry as input to the > algorithm. >=20 > That covers the missing information from above. so having the introduction of the new bit in the higher level behavior = section was the source of confusion? >=20 > When determining which requests are impacted by the overload control > algorithm, request senders MAY take into account the type of message > being sent and its contents. For example, messages within an > existing session may be prioritized over those that create a new > session. The exact rules for such prioritization will likely vary > from application to application. >=20 > This worries me. A lot. Let me explain. >=20 > Having multiple algorithms increases system complexity. Having a > *client* implement algorithms is even more problematic. Maybe = Diameter > is different, but my experience with RADIUS shows that it's best to > assume clients are the dumbest things around. >=20 > Keeping the complexity in the server means that there are fewer = places > in the network which need this complexity. Servers already have a lot > of complexity to deal with various policies, so adding more isn't too > difficult. >=20 > My experience is that it's better to define *actions* for clients, > instead of *states* and algorithms. i.e. "come back in 5 seconds" is > simpler for a client than "server is in state X, please implement > algorithm Y". >=20 > It means that the server can implement *any* algorithm, and all > clients will support it. We only require the "overload" signaling to > include the standard network parameters related to time and bandwidth. >=20 > - send no more than X messages / s > - retransmit this message in X seconds > - etc. >=20 > So the server can run the algorithm, and inform the client as to it's > expected behavior. No negotiation is required. The client just has = to > signal it's capability to understand the time / bandwidth messages. >=20 > It's simpler, easier to understand, easier to implement, and likely = to > be more flexible and robust. yes, Diameter clients are different. They tend to be sophisticated = servers doing a number of functions with Diameter being used for some of = their control signaling. Their other functions usually require the use = of other protocols and they may have to consider information in making = overload control decisions that servers do not have. The requirements = draft may be helpful for describing the problem domain for this = (http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09) >=20 > The rest of the document describes such signaling. But calling it > "Overload" confuses the issue (IMHO). Maybe it could be "messaging > QoS", or something similar. The idea is that it's *normal* to signal > changing circumstances between peers. It's not an exceptional or > "overload" situation. interesting idea on renaming. I'm curious what others think of this. >=20 > e.g. Say I want to switch traffic from server A to server B. To do = it > gradually, I make server A signal that it has gradually lower = throughput > over time, and server B signals it has gradually higher throughput = over > time. >=20 > The end result is that the traffic moves from A to B without any > sudden "spikes". The alternative would be to suddenly signal that > server A is down, and all of the clients have to suddenly deal with = the > loss of a server. >=20 > Section 3.5 Load Processing >=20 > While the remainder of the mechanism described in this document is > aimed at handling overload situations once they occur, it is far > better for a system if overload can be avoided altogether. In order > to facilitate overload avoidance, the overload mechanism includes = the > ability to convey node load information. >=20 > I agree here. I think this document doesn't go far enough. As I = said > above, load signaling is *normal*. Overload is just a signal that > accepted load is approaching zero. >=20 > I suggest revamping the document to treat load changes as normal, > rather than as exceptional. It would make it clearer (to me, at = least) > what the goal is: managing traffic. Instead of managing exceptional > circumstances. Good comment. A pass through to emphasize proactive control more could = be helpful. >=20 > 3.5.1. Sending Load Information >=20 > As noted earlier, I have objections to this approach. Signaling load > information is confusing to me. e.g. "OK, the server is overloaded... > what do I *do* now?" The load information is the info used for proactive mitigation. It = carries no implication that overload is happening. That is handled by = the rest of the information. As far as what to do with it, not specifying that was intentional. What = to do with load information is implementation specific. Load balancing = is what usually pops into people's heads. But that is not the only = option. I think part of the confusion here may be Load-Info (grouped) vs. Load = (reported load for proactive mitigation) AVP naming. This has caught me = before too. I think renaming Load-Info to Overload-Control-Info or some = such would be helpful. I understand your earlier comment about naming = to indicate that this is ongoing information, but we also need to be = careful not to imply that the information is intended for uses other = than overload control (that can certainly be done, but we need to = constrain what we are designing for). >=20 > It should be something like "Signaling Connection Parameters" or > "Signaling Requested Sending Behavior". That is an *active* = statement. > "Signaling Load Information" is a *passive* statement. It doesn't = lead > the reader to believe he needs to *do* anything with the information. There isn't any requirement for a recipient to do anything with the = information. In many cases they can do things that will help with = proactive overload mitigation though, such as the simple load balancing = example. >=20 > ... > The client then examines the currently reported loads for each of = the > three servers. In this example, we are asserting that the reported > load metrics are as follows: >=20 > This section is a bit opaque to me. It's not clear *why* these > calculations are being done. I presume it's taking a convolution of = the > suggested load distribution with the servers current load. But it's = not > clear. this example just uses the load information to scale SRV weights, so you = have the gist of it. It is non-normative and just an example of how = load information can be used. Perhaps some of the discussed name = changing will help illustrate that the load information usage is = different than the reactive overload control information. >=20 > ... > A Diameter node entering the overload state for any of the scopes > that it uses with its peers will calculate a value for its Overload > Metric, in the range of 0 to 100 (inclusive). This value indicates > the percentage traffic reduction the Diameter node wishes its peers > to implement. >=20 > This is good. I would prefer that the earlier parts of the document > explain the method. i.e. the earlier parts have motivation, but not a > short description of how it works. Such explanations serve to = motivate > the rest of the document, and put it into a conceptual framework. We could talk about this earlier as an example. The actual behavior = though depends on the algorithm and is extensible, so we have to be = careful not to paint the language into a corner. >=20 > I have concerns with signaling a percentage traffic reduction. What > if the server is overloaded, signals a reduction, and the traffic has > already lowered? The client would seem to lower it's already lowered > traffic. The client then sends less traffic than the server can = accept. >=20 > It would be better to signal throughput instead. i.e. "limit > throughput to X messages/s". When the traffic on the client lowers, = it > discovers that it is already compliant with the request. And does = nothing. you're not the only one to think that :-) we have to pick a default = algorithm to use and drop has the nice characteristic of being quite = simple. What actually happens here is up for debate. >=20 >=20 > That's my $0.02 for now. >=20 > Alan DeKok. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From md3135@att.com Thu Jul 25 05:47:56 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 F39B921F8BE6 for ; Thu, 25 Jul 2013 05:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG6vnBJSBIHe for ; Thu, 25 Jul 2013 05:47:49 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 123F921F8BD8 for ; Thu, 25 Jul 2013 05:47:49 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 57e11f15.5fae4940.1496584.00-567.4118822.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 25 Jul 2013 12:47:49 +0000 (UTC) X-MXL-Hash: 51f11e75113883e5-9158bb2a0ac4d11a3be9cad84b8b86a430339db4 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 76e11f15.0.1496484.00-332.4118549.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 25 Jul 2013 12:47:40 +0000 (UTC) X-MXL-Hash: 51f11e6c39bfdd57-3276700e17c713ee49b4f404c351434af77d6665 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6PClY6X004602; Thu, 25 Jul 2013 08:47:35 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6PClMep004470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 08:47:26 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 25 Jul 2013 12:47:15 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 08:47:15 -0400 From: "DOLLY, MARTIN C" To: Eric McMurry , Alan DeKok Thread-Topic: [Dime] Review of draft-roach-dime-overload-ctrl-03 Thread-Index: AQHOiRB8FXsHZwRZMEOcn1r0dwj0EZl1VzZQ Date: Thu, 25 Jul 2013 12:47:15 +0000 Message-ID: References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.86.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RAZr76BvmEwA:10 a=6TrqOlPLx_kA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=DVOwvlPujloA:10 a=48vgC7mUAAAA:8 a=8yKjGgpNJl8653] X-AnalysisOut: [jHuAUA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-roach-dime-overload-ctrl-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: Thu, 25 Jul 2013 12:47:56 -0000 Eric, I prefer "Overload" versus QoS messaging" Regards, Martin -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: Thursday, July 25, 2013 4:25 AM To: Alan DeKok Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-roach-dime-overload-ctrl-03 Hi Alan, Thanks for the taking the time to provide comments! discussion inline. Eric >=20 > The rest of the document describes such signaling. But calling it > "Overload" confuses the issue (IMHO). Maybe it could be "messaging > QoS", or something similar. The idea is that it's *normal* to signal > changing circumstances between peers. It's not an exceptional or > "overload" situation. interesting idea on renaming. I'm curious what others think of this. From aland@deployingradius.com Thu Jul 25 05:50:15 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 1700C21F9633 for ; Thu, 25 Jul 2013 05:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO7EM61jZdFI for ; Thu, 25 Jul 2013 05:50:10 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98EFE21F8C72 for ; Thu, 25 Jul 2013 05:50:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8228F224012C; Thu, 25 Jul 2013 14:50:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDz00KUKy0YR; Thu, 25 Jul 2013 14:50:05 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 58B5F2240061; Thu, 25 Jul 2013 14:50:05 +0200 (CEST) Message-ID: <51F11EFE.7040109@deployingradius.com> Date: Thu, 25 Jul 2013 08:50:06 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eric McMurry References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Review of 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, 25 Jul 2013 12:50:15 -0000 Eric McMurry wrote: > I understand your point about out of band. That would make sense for several reasons. However, using the existing protocol is highly desirable since it is already in place and can support this. Using the existing protocol is fine. I'm just wary of overloading a link-layer QoS protocol, and turning into a multi-hop routing protocol. It would be better (IMHO) to signal routing changes independent from link changes. > so having the introduction of the new bit in the higher level behavior section was the source of confusion? Yes. If the first use of "overload metric" assumes you know the meaning, it's confusing. e.g. Section 1.3 says: ... Overload-Metric (which is input to the negotiated load abatement algorithm). It might as well be called "foo". It's an opaque input parameter, with no meaning, and no context. I find it clearer to lay out the document by introducing a concept, defining it, giving a hint as to how it's used, and then later using it in a more complex context. > yes, Diameter clients are different. They tend to be sophisticated servers doing a number of functions with Diameter being used for some of their control signaling. Their other functions usually require the use of other protocols and they may have to consider information in making overload control decisions that servers do not have. The requirements draft may be helpful for describing the problem domain for this (http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09) I scanned it. I'll take a deeper look. > As far as what to do with it, not specifying that was intentional. What to do with load information is implementation specific. Then I'm not sure why this document is useful. It would seem to be useful to describe both the data, and how the data is used. >> This section is a bit opaque to me. It's not clear *why* these >> calculations are being done. I presume it's taking a convolution of the >> suggested load distribution with the servers current load. But it's not >> clear. > > this example just uses the load information to scale SRV weights, so you have the gist of it. It is non-normative and just an example of how load information can be used. Perhaps some of the discussed name changing will help illustrate that the load information usage is different than the reactive overload control information. I was looking for an English explanation of what was going on. Right now, the calculation looks a lot like: A = 5 B = 6 C = 10 D = A * B / C + 2*A E = D^A + C ??? OK, that's nice. WHY is this being done? What does it mean? > you're not the only one to think that :-) we have to pick a default algorithm to use and drop has the nice characteristic of being quite simple. What actually happens here is up for debate. Traffic is bursty. Let's say a server gets a burst of 100Mbps traffic. It signals to the client "drop traffic by 90%". By the time the message makes it to the client, the burst is over. Traffic is down to 5Mbps. So the client happily caps it at .5Mbps, which is not what the server wanted. Signaling a percentage drop is meaningless, because it's taken at a time on the server. The client doesn't know when that measurement was done on the server. So either you signal "percentage drop AND (servers' load OR server time)", or you just signal "limit traffic to X bps". Both have the same effect. The second is simpler. Alan DeKok. From jgunn6@csc.com Thu Jul 25 07:59:44 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 7C2A321F9957; Thu, 25 Jul 2013 07:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOBYzLR0Nb6w; Thu, 25 Jul 2013 07:59:39 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 44DC121F8994; Thu, 25 Jul 2013 07:59:39 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-3.tower-171.messagelabs.com!1374764375!17336443!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12094 invoked from network); 25 Jul 2013 14:59:36 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-3.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Jul 2013 14:59:36 -0000 Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r6PEutQR013865; Thu, 25 Jul 2013 10:56:55 -0400 In-Reply-To: <51F11EFE.7040109@deployingradius.com> References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> <51F11EFE.7040109@deployingradius.com> To: Alan DeKok MIME-Version: 1.0 X-KeepSent: BA479145:2D221CAB-85257BB3:00508CF7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Thu, 25 Jul 2013 10:59:32 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/25/2013 10:53:11 AM, Serialize complete at 07/25/2013 10:53:11 AM Content-Type: multipart/alternative; boundary="=_alternative 0052664985257BB3_=" Cc: dime-bounces@ietf.org, "dime@ietf.org" Subject: Re: [Dime] Review of 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, 25 Jul 2013 14:59:44 -0000 This is a multipart message in MIME format. --=_alternative 0052664985257BB3_= Content-Type: text/plain; charset="US-ASCII" You might also want to take a look at draft-ietf-soc-overload-control-13 and draft-ietf-soc-overload-rate-control-04 While SIP is different from DIME, the SIP overload work was, in some senses, the "inspiration" for the DIME overload work, and some of the same issues were addressed. In particular, there was the same concern about "loss based" vs "rate based" throttling, resulting in two separate drafts. Both use the same (in band) communications protocol, and the same parameters, but use different parameter values , and different default algorithms. I agree that it is, in general, better for the server to tell the client "do this", rather than "this is my status, you figure out what to do". But DIME may not match the "in general" situation. Janet dime-bounces@ietf.org wrote on 07/25/2013 08:50:06 AM: > From: Alan DeKok > To: Eric McMurry > Cc: "dime@ietf.org" > Date: 07/25/2013 08:50 AM > Subject: Re: [Dime] Review of > Sent by: dime-bounces@ietf.org > > > > yes, Diameter clients are different. They tend to be > sophisticated servers doing a number of functions with Diameter > being used for some of their control signaling. Their other > functions usually require the use of other protocols and they may > have to consider information in making overload control decisions > that servers do not have. The requirements draft may be helpful for > describing the problem domain for this (http://tools.ietf.org/html/ > draft-ietf-dime-overload-reqs-09) > > I scanned it. I'll take a deeper look. > --=_alternative 0052664985257BB3_= Content-Type: text/html; charset="US-ASCII" You might also want to take a look at

draft-ietf-soc-overload-control-13


 and

draft-ietf-soc-overload-rate-control-04


While SIP is different from DIME, the SIP overload work was, in some senses, the "inspiration" for the DIME overload work, and some of the same issues were addressed.

In particular, there was the same concern about "loss based" vs "rate based" throttling, resulting in two separate drafts.  Both use the same (in band)  communications protocol, and the same parameters, but use different parameter values , and different default algorithms.

I agree that it is, in general, better  for the server to tell the client "do this", rather than "this is my status, you figure out what to do".  But DIME may not match the "in general" situation.

Janet



dime-bounces@ietf.org wrote on 07/25/2013 08:50:06 AM:

> From: Alan DeKok <aland@deployingradius.com>
> To: Eric McMurry <emcmurry@computer.org>
> Cc: "dime@ietf.org" <dime@ietf.org>
> Date: 07/25/2013 08:50 AM
> Subject: Re: [Dime] Review of
> Sent by: dime-bounces@ietf.org
>
>
> > yes, Diameter clients are different.  They tend to be
> sophisticated servers doing a number of functions with Diameter
> being used for some of their control signaling.  Their other
> functions usually require the use of other protocols and they may
> have to consider information in making overload control decisions
> that servers do not have.  The requirements draft may be helpful for
> describing the problem domain for this (http://tools.ietf.org/html/
> draft-ietf-dime-overload-reqs-09)
>
>   I scanned it.  I'll take a deeper look.
> --=_alternative 0052664985257BB3_=-- From ben@nostrum.com Thu Jul 25 09:08:32 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 7303521F9433; Thu, 25 Jul 2013 09:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2F0lQnzuOoA; Thu, 25 Jul 2013 09:08:31 -0700 (PDT) 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 39DB121F84EF; Thu, 25 Jul 2013 09:08:31 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6PG8JBV036839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 11:08:22 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Thu, 25 Jul 2013 11:08:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> <51F11EFE.7040109@deployingradius.com> To: Janet P Gunn X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: dime-bounces@ietf.org, "dime@ietf.org" Subject: Re: [Dime] Review of 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, 25 Jul 2013 16:08:32 -0000 On Jul 25, 2013, at 9:59 AM, Janet P Gunn wrote: > You might also want to take a look at >=20 > draft-ietf-soc-overload-control-13=20 >=20 >=20 > and >=20 > draft-ietf-soc-overload-rate-control-04 >=20 >=20 > While SIP is different from DIME, the SIP overload work was, in some = senses, the "inspiration" for the DIME overload work, and some of the = same issues were addressed.=20 >=20 > In particular, there was the same concern about "loss based" vs "rate = based" throttling, resulting in two separate drafts. Both use the same = (in band) communications protocol, and the same parameters, but use = different parameter values , and different default algorithms.=20 >=20 > I agree that it is, in general, better for the server to tell the = client "do this", rather than "this is my status, you figure out what to = do". But DIME may not match the "in general" situation.=20 It may also be worth pointing out that, at least in = draft-roach-dime-overload-ctrl, you really don't have a case of "here's = my status, figure it out" in general. Peers negotiate an algorithm, and = that algorithm specifies what the client should do. The algorithms are = extensible, so it would be possible to make one that fits the "sender = figures it out" model, but there's no assumption of that. For the loss-based algorithm included in the draft, the overload metric = specifies a percentage reduction. For example, a metric of 50 means the = client should reduce traffic by 50. While that still gives the client = some leeway in determining which requests to drop, that's considerably = different from saying "I'm 50% overloaded; figure it out." In fact, = while we're sometimes imprecise here in conversation, there's no = assumption in that algorithm that "reduce your offered load by 50%" maps = in any way to "I'm overloaded by 50%". >=20 > Janet=20 >=20 >=20 >=20 > dime-bounces@ietf.org wrote on 07/25/2013 08:50:06 AM: >=20 > > From: Alan DeKok =20 > > To: Eric McMurry =20 > > Cc: "dime@ietf.org" =20 > > Date: 07/25/2013 08:50 AM=20 > > Subject: Re: [Dime] Review of=20 > > Sent by: dime-bounces@ietf.org=20 > >=20 > >=20 > > > yes, Diameter clients are different. They tend to be=20 > > sophisticated servers doing a number of functions with Diameter=20 > > being used for some of their control signaling. Their other=20 > > functions usually require the use of other protocols and they may=20 > > have to consider information in making overload control decisions=20 > > that servers do not have. The requirements draft may be helpful for > > describing the problem domain for this (http://tools.ietf.org/html/ > > draft-ietf-dime-overload-reqs-09) > >=20 > > I scanned it. I'll take a deeper look. > >_______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Thu Jul 25 15:07:48 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 19F0721F8459 for ; Thu, 25 Jul 2013 15:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVg2k6Vi1zFZ for ; Thu, 25 Jul 2013 15:07:46 -0700 (PDT) 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 4A45C21F849C for ; Thu, 25 Jul 2013 15:07:46 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6PM7ZJF077349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 17:07:37 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <51EFE09E.90102@deployingradius.com> Date: Thu, 25 Jul 2013 17:07:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5EF15D77-EB69-4280-9936-E21DD5C5BF25@nostrum.com> References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-roach-dime-overload-ctrl-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: Thu, 25 Jul 2013 22:07:48 -0000 Hi Alan, thanks for the detailed feedback. Please see comments inline: Thanks! Ben. On Jul 24, 2013, at 9:11 AM, Alan DeKok = wrote: > Ben Campbell wrote: >> At risk of this being a big thing to ask--could you also take a look = at draft-roach-dime-overload-ctrl-03? It would be useful to have your = opinion on all the current Diameter overload control proposals. >=20 > Here's my initial impression. I hope it's clear. >=20 > ... > The inclusion of load and > overload information in existing messages has the property that the > frequency with which information can be exchanged increases as load > on the system goes up. >=20 > I would hazard a guess and say that for 99% of the messages between > nodes A and B, the load information is relatively static. i.e. it > changes slowly over time. This means that "always-on" signing is = efficient. >=20 > In the grand scheme of things, it's probably not too much to worry > about. Networks are fast and getting faster. So adding a bit more to > each message isn't serious. >=20 > Adding *periodic* load information to messages would fulfill the same > goal. >=20 As Eric said separately, we've had a fair amount of discussion on this = point. The idea was to avoid forcing the peer to keep too much = state--anytime it needed to worry about "load" it could pull that = information out of the most recent message. > Section 2 - Overload scopes >=20 > To me, in-band signaling like this is a problem. The issue seems to > be that we require a AAA routing protocol. That protocol would signal > whether realm A was reachable, and if so, what path(s) could be used = to > reach it. >=20 > Describing it as a routing protocol seems better to me. As seen by > this comment in Section 3: >=20 It's possible that this proposal could be used as a routing protocol, = but that's not the intended scope, and I don't think that a routing = protocol is would be considered chartered work for DIME. The point of = the proposal is to allow Diameter nodes to proactively request that = peers reduce their offered load. I think this is different than = availability per se, in that a service is either available or it's not. = One can always request offered load be reduced to zero, which I suppose = is the same as "unavailable", but most cases should not need to go that = far. > OPEN ISSUE: SIP Overload Control includes a sequence parameter to > ensure that out-of-order messages do not cause the receiver to act = on > state that is no longer accurate. >=20 > A routing protocol would ensure that state changes are propogated > smoothly through the network, without out-of-order issues. It may use = a > sequence number, but dealing with order would be an explicit design = goal > of the protocol. >=20 draft-roach-dime-overload-ctrl only describes sending overload/load info = between immediate peers. Unlike RADIUS, Diameter only runs over = connection-based transports. Out of order messages should not be a = problem. OTOH, there's been some discussion about allowing overload info = to non-adjacent nodes. If we were to do that, we'd probably need to = think about the possibility of out-of-order messages. > ... > To implement overload control, Diameter nodes need to keep track of > three important metrics for each of the scopes for which information > has been received: the overload metric for the scope, ... >=20 > This is the first introduction of "overload metric". What is it? = What > does it mean? As Eric mentioned, it's first described in the 2nd paragraph of the = introduction. Is that description insufficient? >=20 > ... > In order to allow recipients of overload information to perform > certain performance optimizations, we also define a new command = flag, > called 'O'verload. This bit, when set, indicates that the message > contains at least one Load-Info AVP with a non-zero Overload-Metric > -- in other words, the sending node is overloaded for at least one > context. See Section 7.4 for the definition of the 'O'verload bit. >=20 > What does the overload bit *mean*? The sending node is overloaded. > Ok... what does the client *do* with that information? There should = be > a sentence here introducing the idea that the client does something = with > the data. >=20 I'm not sure I understand the confusion on this one. The O flag means = that the message contains overload information, in the form of a = Load-Info AVP with a non-zero Overload-Metric value. Would it help to = remove the mention of the Load-Info AVP and Overload-Metric and simply = say " ... indicates that the message contains information about an = active overload condition"? > Later, we have an explanation: >=20 > If one or more matching scope entries are in overload, then the > sending node determines which scope is most overloaded. The sending > node then sends, drops, or otherwise modifies handling of the = request > according to the negotiated overload control algorithm, using the > Overload-Metric from the selected scope entry as input to the > algorithm. >=20 > That covers the missing information from above. Actually, that describes the meaning of the overload information in the = message, but not the overload flag. The flag is entirely an optimization = so the peer knows to look for the overload metric. We spoke to = implementors that were concerned about having to parse the entire = message to determine if they needed to apply overload treatments. The = flag gives a fast way to determine that. Basically, the assertion of an = overload condition is entirely done inside the Load-Info AVP. The flag = has no semantic meaning beyond "look in Load-Info, there's important = stuff there.") This could probably use clarification. >=20 > When determining which requests are impacted by the overload control > algorithm, request senders MAY take into account the type of message > being sent and its contents. For example, messages within an > existing session may be prioritized over those that create a new > session. The exact rules for such prioritization will likely vary > from application to application. >=20 > This worries me. A lot. Let me explain. >=20 That's probably badly written. The point is not that request senders get = to decide which messages are impacted by the overload control algorithm. = That's handled explicitly by the scope AVPs. The point is, that when = deciding which messages to drop among the set of impacted messages, the = client has some leeway. For example, if using the "loss" algorithm with = an overload-metric of 50, the client gets to decide which 50% messages = gets dropped. (Note that some other algorithm could include stricter = rules). > Having multiple algorithms increases system complexity. Having a > *client* implement algorithms is even more problematic. Maybe = Diameter > is different, but my experience with RADIUS shows that it's best to > assume clients are the dumbest things around. There are areas where Diameter is different, and areas where it is not. = It does tend to support more complex applications that RADIUS, where = there may be more application-specific request interdependencies. But = even if it were the same, I don't know how a server could tell the = client what to do with messages that haven't been sent yet. > Keeping the complexity in the server means that there are fewer = places > in the network which need this complexity. Servers already have a lot > of complexity to deal with various policies, so adding more isn't too > difficult. >=20 The reasoning is the client understands more about the underlying = application, and any resulting request interdependencies, than the = server.=20 > My experience is that it's better to define *actions* for clients, > instead of *states* and algorithms. i.e. "come back in 5 seconds" is > simpler for a client than "server is in state X, please implement > algorithm Y". I think there's a bit of a misconception there. The point is not to say = " the server is in state X, please implement Y". The algorithm is = negotiated up front. The Overload-Metric is an input into that = algorithm. It really isn't a description of server state. For example, = if the loss algorithm is in effect, a Overload-Metric of 50% means = "reduce offered load by 50% (of what you would have otherwise sent)". It = does _not_ mean "I am overloaded by 50%". (The client might could infer = that, but I suspect it would not be correct a good bit of the time.) >=20 > It means that the server can implement *any* algorithm, and all > clients will support it. We only require the "overload" signaling to > include the standard network parameters related to time and bandwidth. >=20 > - send no more than X messages / s I'm not sure how, from the perspective of your previous concerns, this = is any different. The client still gets to decide which X messages make = the cut any given second. And in the context of the draft, this is no = different than negotiating a rate-limit application which interprets the = Overload-Metric to be a number of messages per second, then sending an = overload metric of X. (Admittedly the draft does not describe a rate-limit algorithm, but = there's been discussion that we may need one.) > - retransmit this message in X seconds That falls into the category of reactive vs proactive overload control. = I think it might be worthwhile fixing DIAMETER_TOO_BUSY to allow a = server to express that sort of thing. But I think we would do that in a = separate draft. > - etc. >=20 > So the server can run the algorithm, and inform the client as to it's > expected behavior. No negotiation is required. The client just has = to > signal it's capability to understand the time / bandwidth messages. >=20 How is signaling the capacity to understand the time/bandwidth messages = different than negotiating support for a rate-limit algorithm? > It's simpler, easier to understand, easier to implement, and likely = to > be more flexible and robust. >=20 > The rest of the document describes such signaling. But calling it > "Overload" confuses the issue (IMHO). Maybe it could be "messaging > QoS", or something similar. The idea is that it's *normal* to signal > changing circumstances between peers. It's not an exceptional or > "overload" situation. >=20 > e.g. Say I want to switch traffic from server A to server B. To do = it > gradually, I make server A signal that it has gradually lower = throughput > over time, and server B signals it has gradually higher throughput = over > time. >=20 > The end result is that the traffic moves from A to B without any > sudden "spikes". The alternative would be to suddenly signal that > server A is down, and all of the clients have to suddenly deal with = the > loss of a server. >=20 I think this can be accomplished with the "Load" information. I can see = separating that out as a separate mechanism. We've included it because = we think the overload aspects can work a lot better if you know = something about the active load going on in non-overloaded nodes. Peers = can make smarter decisions about how to reduce load on an overloaded = server. In particular, we have a requirement to not cause cascade = failures or unstable oscillations. Basically we want to avoid causing a = second node to go into overload because we moved traffic there from a = previously overloaded node. > Section 3.5 Load Processing >=20 > While the remainder of the mechanism described in this document is > aimed at handling overload situations once they occur, it is far > better for a system if overload can be avoided altogether. In order > to facilitate overload avoidance, the overload mechanism includes = the > ability to convey node load information. >=20 > I agree here. I think this document doesn't go far enough. As I = said > above, load signaling is *normal*. Overload is just a signal that > accepted load is approaching zero. >=20 > I suggest revamping the document to treat load changes as normal, > rather than as exceptional. It would make it clearer (to me, at = least) > what the goal is: managing traffic. Instead of managing exceptional > circumstances. To be clear, changes in "load" are not exceptional, and can be used as = an input into load balancing at any time. That differs from "overload", = which can be best interpreted as "I urgently need a reduction in offered = load". >=20 > 3.5.1. Sending Load Information >=20 > As noted earlier, I have objections to this approach. Signaling load > information is confusing to me. e.g. "OK, the server is overloaded... > what do I *do* now?" This section is not about overload. It's about current load in = non-overloaded conditions. I'm not sure how that's different from the = "non-exceptional" load processing you mentioned in the previous = paragraphs. > It should be something like "Signaling Connection Parameters" or > "Signaling Requested Sending Behavior". That is an *active* = statement. > "Signaling Load Information" is a *passive* statement. It doesn't = lead > the reader to believe he needs to *do* anything with the information. >=20 > ... > The client then examines the currently reported loads for each of = the > three servers. In this example, we are asserting that the reported > load metrics are as follows: >=20 > This section is a bit opaque to me. It's not clear *why* these > calculations are being done. I presume it's taking a convolution of = the > suggested load distribution with the servers current load. But it's = not > clear. >=20 There are two aspects of load. One is relative static capacity. For = example, are all the servers in a cluster the same size? In Diameter, = that can be expressed with the DNS SRV "weight" field (as in the = example). It can also be provisioned into a peer table. The other is = dynamic load, i.e. how loaded is the server right now.=20 The idea is that 50% availability of a big server is different than 50% = availability of a small server. (I suspect you are right that there is room for clarification in the = text.) > ... > A Diameter node entering the overload state for any of the scopes > that it uses with its peers will calculate a value for its Overload > Metric, in the range of 0 to 100 (inclusive). This value indicates > the percentage traffic reduction the Diameter node wishes its peers > to implement. >=20 > This is good. I would prefer that the earlier parts of the document > explain the method. i.e. the earlier parts have motivation, but not a > short description of how it works. Such explanations serve to = motivate > the rest of the document, and put it into a conceptual framework. Keep in mind, this is how the "loss" algorithm works, and it's in the = section defining the loss algorithm. Other algorithms could interpret = Overload-Metric differently. (e.g. the previous example of a rate-limit = algorithm treating it as max messages per second.) The idea is that the mechanism in the draft is a framework that allows = extensible algorithms.The previous sections talk about how the = overload-metric AVP is an input into the agreed algorithm.=20 That being said, there's almost always room for clarification, and we = might could do something in the earlier sections like "Overload-Metric = is an input into the negotiated overload-abatement algorithm. For = example, in the "loss" algorithm [section X], Overload-Metric indicates = a percentage traffic reduction" >=20 > I have concerns with signaling a percentage traffic reduction. What > if the server is overloaded, signals a reduction, and the traffic has > already lowered? The client would seem to lower it's already lowered > traffic. The client then sends less traffic than the server can = accept. >=20 > It would be better to signal throughput instead. i.e. "limit > throughput to X messages/s". When the traffic on the client lowers, = it > discovers that it is already compliant with the request. And does = nothing. >=20 There's room for discussion as to whether "loss" is the best choice for = the mandatory-to-implement algorithm. It has the advantage of being = simple to implement, and has been shown to work well in other areas = (e.g. SIP Overload). OTOH, I think a number of working group = participants would prefer a rate-limit algorithm as the mandatory to = implement. In any case, algorithms are extensible. We can always add new ones as we = get deployment experience. >=20 > That's my $0.02 for now. >=20 > Alan DeKok. From ben@nostrum.com Thu Jul 25 15:22: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 6F14421F8F24 for ; Thu, 25 Jul 2013 15:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-YCCsMfy3fz for ; Thu, 25 Jul 2013 15:22:46 -0700 (PDT) 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 0DD8C21F85B4 for ; Thu, 25 Jul 2013 15:22:44 -0700 (PDT) Received: from [10.0.1.27] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6PMMgaV078958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 17:22:42 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Thu, 25 Jul 2013 17:22:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 25 Jul 2013 22:22:47 -0000 Hi JJaques, see comments inline: On Jul 24, 2013, at 7:59 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 > Dear all >=20 > I hereafter add some comments on two ones made in previous mails. >=20 > - there was the comment " I'm not sure I understand what the implicit = scope is in Hannes's draft".. I agree it would be good Hannes to = clarify his new proposal. =46rom my own reading in = draft-tschofenig-dime-overload-piggybacking in 3.2: > ... the Diameter > server (or a proxy, ....) may decide to communicate to the Diameter > client to reject some or even all Diameter requests. The Diameter > server does so by adding the Overload-Info AVP, which contains the > Overload and the Period-Of-Validity AVP. >=20 > Then the overload AVP indicates to the client the amount of traffic to = decrease or to increase. So from my understanding, it is similar to the = implicit scope I have described as the piggybacked overload info is = related to the message transporting it, and in consequence does not = require to indicate an explicit scope.=20 Do I understand correctly that you assume the traffic that should be = reduced is the set of future requests that have the same realm, = application-Id, and perhaps destination-host/origin-host that matches = that of the message containing the overload report? I don't recall = seeing text in the draft to indicate that, but might have missed = something. (If I did, please don't hesitate to educate me :-) ) > I have other views on the content of the overload info where I am in = favour of an overload info indicating a % of traffic reduction to be = applied. I also consider the overlaod info is used by the throttling = entity which may be the client or an intermediate DA. Hannes only = mentions the client. That would be similar to what is in draft-roach-dime-overload-ctrl, when = used with the included "loss" algorithm, right? (ignoring for the moment = issues of crossing non-supporting agents) >=20 > - about the comment "do you mean a default? (that is, one that applies = if no scope is explicitly included)?". The implicit scope I have = described is not a default scope, in the above meaning. It is implicit = because it applies to the traffic to which the message conveying the = overload info belongs. This scope is not exclusive of other scopes, but = for the many cases that it covers by itself, I do not foresee to use = it in conjunction with others. As mentioned, I would like to know use = cases, that this implicit scope will not cover and which other scopes or = extensions would be required. The Roach draft currently has a "Connection" scope that takes it's value = from the connection on which the report arrived. It's an explicitly = included scope, but it's value is implicit. Is that the sort of thing = you have in mind, but for a different set of implicit values? That is, = we could have sort of a "this realm and application" scope? You would = explicitly include it, but the realm and application-ID values would be = implied by the message contents? Thanks! Ben.= From kishore.kumar-jv@hp.com Thu Jul 25 21:04:51 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 4206D21F8D10 for ; Thu, 25 Jul 2013 21:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THB8Mwing6wd for ; Thu, 25 Jul 2013 21:04:44 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 831A121F85BB for ; Thu, 25 Jul 2013 21:04:39 -0700 (PDT) Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id EAA948EC8 for ; Fri, 26 Jul 2013 04:04:38 +0000 (UTC) Received: from G4W6303.americas.hpqcorp.net (16.210.26.228) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 26 Jul 2013 03:59:33 +0000 Received: from G4W3220.americas.hpqcorp.net ([169.254.9.24]) by G4W6303.americas.hpqcorp.net ([16.210.26.228]) with mapi id 14.03.0123.003; Fri, 26 Jul 2013 03:59:34 +0000 From: "J V, Kishore Kumar (Communication & Media Solutions)" To: "dime@ietf.org" Thread-Topic: Question On Proxy-Info AVP Thread-Index: Ac6JsuXfVfDa6ZNfRF+jbUDMhSs90A== Date: Fri, 26 Jul 2013 03:59:33 +0000 Message-ID: <91B0F3EF3C5AAF48BA287620E268D55E1833DDD9@G4W3220.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.23] Content-Type: multipart/alternative; boundary="_000_91B0F3EF3C5AAF48BA287620E268D55E1833DDD9G4W3220americas_" MIME-Version: 1.0 Subject: [Dime] Question On Proxy-Info AVP 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, 26 Jul 2013 04:04:51 -0000 --_000_91B0F3EF3C5AAF48BA287620E268D55E1833DDD9G4W3220americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We support a heterogeneous architecture of diameter stack w= here the actual stack runs on a network front-end machine, with diameter ap= plication (eg., HSS) running on the back-end machines. So far this front-en= d network stack was stateful i.e. if it had sent an outgoing request, it kn= ew to which back-end machine the response has to be routed to. This state-full property brings-in some issues and thus we're planning on t= o make the network front-end stack stateless. For this, we need the ability= to have some information to be put in the request with the guarantee that = the same will be returned in the response - basically the state information= . For stateless agents, RFE already defines the Proxy-Info AVP for storing = and retrieval for their state information. There has been suggestion to use= the same for a new outgoing - not forwarded - requests. We know that AVP n= ame itself implies that only agents can utilize them. But, can this be poss= ible to use this AVP for new outgoing request to store the stateless inform= ation? Is this practiced anywhere? How do the popular implementation of sta= ck/diameter application deal with a 'Proxy-Info' AVP without let's say a Ro= ute-Record AVP - i.e. Only if Route-Record AVP is present, it means it has = passed through an agent? Please let us know your opinion on this. Thanks, Kishore --_000_91B0F3EF3C5AAF48BA287620E268D55E1833DDD9G4W3220americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

        &nbs= p;       We support a heterogeneous architect= ure of diameter stack where the actual stack runs on a network front-end ma= chine, with diameter application (eg., HSS) running on the back-end machine= s. So far this front-end network stack was stateful i.e. if it had sent an outgoing request, it knew to which bac= k-end machine the response has to be routed to.

 

This state-full property = brings-in some issues and thus we’re planning on to make the network = front-end stack stateless. For this, we need the ability to have some infor= mation to be put in the request with the guarantee that the same will be returned in the response – basically the state= information. For stateless agents, RFE already defines the Proxy-Info AVP = for storing and retrieval for their state information. There has been sugge= stion to use the same for a new outgoing – not forwarded – requests. We know that AVP name itself impli= es that only agents can utilize them. But, can this be possible to use this= AVP for new outgoing request to store the stateless information? Is this p= racticed anywhere? How do the popular implementation of stack/diameter application deal with a ‘Proxy-Info’ AVP wit= hout let’s say a Route-Record AVP – i.e. Only if Route-Record A= VP is present, it means it has passed through an agent?

 

Please let us know your o= pinion on this.

 

Thanks,

Kishore

 

--_000_91B0F3EF3C5AAF48BA287620E268D55E1833DDD9G4W3220americas_-- From emcmurry@computer.org Fri Jul 26 06:10:28 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 C6B2D21F9935 for ; Fri, 26 Jul 2013 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzXp3MxUXd6D for ; Fri, 26 Jul 2013 06:10:24 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03AAC21F9926 for ; Fri, 26 Jul 2013 06:10:23 -0700 (PDT) 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 1V2hmp-000EpF-C7; Fri, 26 Jul 2013 13:10:23 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 83B72CDB68A; Fri, 26 Jul 2013 08:10:21 -0500 (CDT) 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: U2FsdGVkX1/13l7yECpIOjr4Gn06XYvc+qL7Ek8P4HU= 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 FcQwBTncli4X; Fri, 26 Jul 2013 08:10:21 -0500 (CDT) Received: from [192.168.13.6] (unknown [192.168.13.6]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 66C39CDB67A; Fri, 26 Jul 2013 08:10:18 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <51F11EFE.7040109@deployingradius.com> Date: Thu, 25 Jul 2013 23:36:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14A3737E-B429-4895-B396-B0A48C15CBAF@computer.org> References: <51EF1A3D.802@deployingradius.com> <51EFE09E.90102@deployingradius.com> <51F11EFE.7040109@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1508) Cc: "dime@ietf.org" Subject: Re: [Dime] Review of 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, 26 Jul 2013 13:10:28 -0000 On Jul 25, 2013, at 14:50 , Alan DeKok = wrote: > Eric McMurry wrote: >> I understand your point about out of band. That would make sense for = several reasons. However, using the existing protocol is highly = desirable since it is already in place and can support this. >=20 > Using the existing protocol is fine. I'm just wary of overloading a > link-layer QoS protocol, and turning into a multi-hop routing = protocol. >=20 > It would be better (IMHO) to signal routing changes independent from > link changes. I'm still a bit lost here. This signaling piggybacks directly in = Diameter messages and doesn't define any link or transport protocols. = It does not signal link changes or routing changes. Can you point me to = the language in the draft that is giving that impression? >=20 >> so having the introduction of the new bit in the higher level = behavior section was the source of confusion? >=20 > Yes. If the first use of "overload metric" assumes you know the > meaning, it's confusing. e.g. Section 1.3 says: >=20 > ... Overload-Metric (which is input to the negotiated > load abatement algorithm). >=20 > It might as well be called "foo". It's an opaque input parameter, > with no meaning, and no context. >=20 > I find it clearer to lay out the document by introducing a concept, > defining it, giving a hint as to how it's used, and then later using = it > in a more complex context. >=20 >> yes, Diameter clients are different. They tend to be sophisticated = servers doing a number of functions with Diameter being used for some of = their control signaling. Their other functions usually require the use = of other protocols and they may have to consider information in making = overload control decisions that servers do not have. The requirements = draft may be helpful for describing the problem domain for this = (http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09) >=20 > I scanned it. I'll take a deeper look. understood. It was a good review for a scan. I wasn't complaining, = just trying to answer your question. >=20 >> As far as what to do with it, not specifying that was intentional. = What to do with load information is implementation specific. >=20 > Then I'm not sure why this document is useful. It would seem to be > useful to describe both the data, and how the data is used. There is more than one thing going on here. I was talking about the = load information used for proactive mitigation. The document also = describes overload control information which has more constraints on its = usage. >=20 >>> This section is a bit opaque to me. It's not clear *why* these >>> calculations are being done. I presume it's taking a convolution of = the >>> suggested load distribution with the servers current load. But it's = not >>> clear. >>=20 >> this example just uses the load information to scale SRV weights, so = you have the gist of it. It is non-normative and just an example of how = load information can be used. Perhaps some of the discussed name = changing will help illustrate that the load information usage is = different than the reactive overload control information. >=20 > I was looking for an English explanation of what was going on. Right > now, the calculation looks a lot like: >=20 > A =3D 5 > B =3D 6 > C =3D 10 >=20 > D =3D A * B / C + 2*A > E =3D D^A + C >=20 > ??? OK, that's nice. WHY is this being done? What does it mean? Does the text in 3.4 talking about proactive mitigation help with this? >=20 >> you're not the only one to think that :-) we have to pick a default = algorithm to use and drop has the nice characteristic of being quite = simple. What actually happens here is up for debate. >=20 > Traffic is bursty. Let's say a server gets a burst of 100Mbps > traffic. It signals to the client "drop traffic by 90%". By the time > the message makes it to the client, the burst is over. Traffic is = down > to 5Mbps. So the client happily caps it at .5Mbps, which is not what > the server wanted. >=20 > Signaling a percentage drop is meaningless, because it's taken at a > time on the server. The client doesn't know when that measurement was > done on the server. >=20 > So either you signal "percentage drop AND (servers' load OR server > time)", or you just signal "limit traffic to X bps". Both have the = same > effect. The second is simpler. This depends entirely on the traffic mix and the number of clients. In = some cases it is true, in others (i.e. less bursty traffic, large = numbers of clients, ...), it is not. I don't disagree that rate based = control would be better in many instances. It requires more = consideration for the types of use cases and topologies that are = expected to be typical (similar to what happened in SIP overload as = Janet pointed out). Of course, either one may not be appropriate in = some cases, which is why it's extensible. Thanks for the vote on rate = based. I think there will be more discussion on this coming from = several folks. From bclaise@cisco.com Fri Jul 26 09:15: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 1512011E8105 for ; Fri, 26 Jul 2013 09:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg13--ylMQ5P for ; Fri, 26 Jul 2013 09:15:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A211E80F6 for ; Fri, 26 Jul 2013 09:15:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6QGFdsI001382; Fri, 26 Jul 2013 18:15:39 +0200 (CEST) Received: from [10.61.111.237] (dhcp-10-61-111-237.cisco.com [10.61.111.237]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6QGFDeZ025128; Fri, 26 Jul 2013 18:15:29 +0200 (CEST) Message-ID: <51F278F8.3070505@cisco.com> Date: Fri, 26 Jul 2013 15:26:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lionel.morand@orange.com References: <51EE7BBE.1050804@cisco.com> <51EF07E5.7070300@cisco.com> <19162_1374674665_51EFDEE9_19162_49_1_6B7134B31289DC4FAF731D844122B36E231E29@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19162_1374674665_51EFDEE9_19162_49_1_6B7134B31289DC4FAF731D844122B36E231E29@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------020108080506050806000400" Cc: dime mailing list Subject: Re: [Dime] AD review of draft-ietf-dime-realm-based-redirect 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, 26 Jul 2013 16:15:46 -0000 This is a multi-part message in MIME format. --------------020108080506050806000400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Lionel, Thanks for the fast reply. See in line. > > Hi Benoit, > > please see below. > > Regards, > > Lionel (as Doc Shepherd) > > *De :*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *De la part > de* Benoit Claise > *Envoyé :* mercredi 24 juillet 2013 00:47 > *À :* dime mailing list > *Objet :* [Dime] AD review of draft-ietf-dime-realm-based-redirect > > Dear authors, > > Here is my AD review. > If some points have been discussed on the mailing list, don't hesitate to let me know. > > > 1. > The following sentence contains twice "but instead" > > The result of making realm-based redirection an application-specific > behaviour is that it cannot be performed by a redirect agent, but > instead must be performed by a redirect agent as defined in > [RFC6733 ], but instead by an application-aware Diameter node > (Diameter server or proxy). > > Don't you mean? > > The result of making realm-based redirection an application-specific > behaviour is that it cannot be performed by a redirect agent > [RFC6733 ], but instead by an application-aware Diameter node > (Diameter server or proxy). > */[LM] OK./* > > > 2. > > Because realm-based redirection is not part of the Diameter base > protocol [RFC6733 ], support of realm-based redirection_by a Redirect_ > _ agent_ MUST be specified as part of functionality supported by a > Diameter application. > > This contradicts the following sentence > > The result of making realm-based redirection an application-specific > behaviour is that it cannot be performed by a_redirect agent_ > [RFC6733 ], but instead by an application-aware Diameter node > (Diameter server or proxy). > > Do I understand correctly that the justification is that, citing RFC 6733, Redirect Agents can't inspect the application. > "Diameter relays and redirect agents are transparent to the Diameter > applications, but they MUST support the Diameter base protocol, which > includes accounting, and all Diameter applications." > > I could understand all this if "by a Redirect Agent" would be removed in the first paragraph. > OLD: > Because realm-based redirection is not part of the Diameter base > protocol [RFC6733 ], support of realm-based redirection by a Redirect > agent MUST be specified as part of functionality supported by a > Diameter application. > > NEW: > Because realm-based redirection is not part of the Diameter base > protocol [RFC6733 ], support of realm-based redirection MUST be > specified as part of functionality supported by a Diameter application. > */[LM] Correct/* > > But then, if it doesn't apply to a Redirect Agent, then why do we have this paragraph > However, despite the change in executing > role, the behaviour itself is a slight modification of the behaviour > of a redirect agent as described inSection 2.8.3 of [RFC6733] . > */[LM]My understanding is to point out that the role of the Realm-based redirect proxy/server is very close to the behavior of a "regular" redirect agent, and therefore most of what applies for Redirect agent apply to the Realm-based redirect proxy/server./* OK. So agreed on The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent [RFC6733 ], but instead by an application-aware Diameter node (Diameter server or proxy). The rest of the paragraph is: However, despite the change in executing role, the behaviour itself is a slight modification of the behaviour of a redirect agent as described inSection 2.8.3 of [RFC6733] . Proposal (for the second part of the paragraph): However, despite the change in executing role, the realm-based redirect proxy/server behaviour is only a slight modification of the behaviour of a redirect agent as described inSection 2.8.3 of [RFC6733] . Also, regarding the last point in the email, you should decide if you want to introduce redirecting server or realm-based redirecting server or realm-based redirect proxy/server in the terminology. Just be consistent throughout the doc. > > 3. > An application can specify that realm-based redirection operates only > on the initial message of a session, or on any message of a session. > > "only the initial message" or "on any message of a session" = "on any message of a session", right? > Remove "only", that would make sense with the next sentence in the paragraph. > */[LM] would it be:/*"operates either only on the initial message of a session, or on any message of a session" ok. > *//* > > Same remark for the first paragraph in 3.2.1 > > 4. > I thought about this use case: > "consider the case where an operator has offered a specific > service but no longer wishes to do so. The operator has arranged for > an alternative domain to provide the service." > Don't we need "Redirect-Max-Cache-Time" = "forever"? > Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is not present? > I could not find a definitive answer in the draft or in RFC 6733 > */[LM] A redirection is always a "temporary" info so the Max-Cache-Time is always present when a cache is created./* > The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. > This AVP_MUST be_ present in answer messages whose 'E' bit is set, > whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and > whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon as you need to cache the info). > */About the "forever", you can't say more than "keep the info cached for 136 years". So it is not "forever" but not too bad./* Not that bad indeed. If this is common practice to put pretty high number in Redirect-Max-Cache-Time, fine then. . > *//* > */ /* > 5. > If the redirected request contained a Destination-Host AVP, that > AVP is ignored by the redirecting server. > > Pay attention that you update RFC 6733 > > Proposal > If the redirected request contains a Result-Code AVP set to > DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, > that Destination-Host AVP MUST be ignored by the redirecting server. > > Or > When a directed request contains a Result-Code AVP set to > DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP > content MUST be ignored by the redirecting server. > */[LM] I think that "redirected" is misleading here as "redirected request" is used as "the request to be redirected"./* > */The clarification here is about the fact that as per RFC6733, a request containing a Destination-Host cannot be rerouted:/* > > An example of a case where it is not possible to > > forward the message to an alternate server is when the message has a > > fixed destination, and the unavailable peer is the message's final > > destination (see Destination-Host AVP). Such an error requires that > > the agent return an answer message with the 'E' bit set and the > > Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. > > */ /* > */About ignoring the Destination-Host, I think that it is not possible to say "MUST be ignored" as it will be application-dependent. For instance, one criterion for realm based redirection can be: "only for initial session request when no Destination-host is present". We could say: "The Realm-based redirection MAY be applied even if a Destination-Host AVP is present in the request, depending on the operator-based policy."/* ok > > 6. > A proxy conforming to this specification that receives an answer > message with the Result-Code AVP set to > DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the > original request to a server in a realm identified by a Redirect- > Realm AVP instance in the answer message, or MAY simply forward the > message toward the client. > > It MUST do one of the two things, I guess. Otherwise, doing nothing is also a valid option according to the text. > Please mention it. > */[LM] Any proxy can do something but a proxy conforming to this specification MUST attempt to reroute... and if it fails, MUST forward the indication to the client./* Please change the text then. > > > 7. > Section 3.2.2 > And what if all point of the procedure fail, for all realms, what should happen? > DIAMETER_REDIRECT_INDICATION to the client? > */[LM] yes. See above./* > > > Editorial > - Redirect agent versus redirect agent > - Redirecting Server is a new term AFAICT, and is not really defined (even if we can guess). > Is this intentional? > */[LM] should be introduced in the def section./* /**/thanks and regards, Benoit > > > Regards, Benoit > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------020108080506050806000400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Lionel,

Thanks for the fast reply.
See in line.

Hi Benoit,

 

please see below.

 

Regards,

 

Lionel (as Doc Shepherd)

 

De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Benoit Claise
Envoyé : mercredi 24 juillet 2013 00:47
À : dime mailing list
Objet : [Dime] AD review of draft-ietf-dime-realm-based-redirect

 

Dear authors,
 
Here is my AD review.
If some points have been discussed on the mailing list, don't hesitate to let me know.
 
 
1.
The following sentence contains twice "but instead"
 
   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent, but
   instead must be performed by a redirect agent as defined in
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy). 
 
Don't you mean?
 
   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent 
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy). 
[LM] OK.
 
 
2.
 
   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection by a Redirect
   agent MUST be specified as part of functionality supported by a
   Diameter application.
   
This contradicts the following sentence
  
   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent 
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy).
 
Do I understand correctly that the justification is that, citing RFC 6733, Redirect Agents can't inspect the application.
   "Diameter relays and redirect agents are transparent to the Diameter
   applications, but they MUST support the Diameter base protocol, which
   includes accounting, and all Diameter applications." 
 
I could understand all this if "by a Redirect Agent" would be removed in the first paragraph.
OLD:
   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection by a Redirect
   agent MUST be specified as part of functionality supported by a
   Diameter application.
 
NEW:
   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection MUST be 
   specified as part of functionality supported by a Diameter application.
[LM] Correct
 
But then, if it doesn't apply to a Redirect Agent, then why do we have this paragraph
   However, despite the change in executing
   role, the behaviour itself is a slight modification of the behaviour
   of a redirect agent as described in Section 2.8.3 of [RFC6733]. 
[LM]My understanding is to point out that the role of the Realm-based redirect proxy/server is very close to the behavior of a "regular" redirect agent, and therefore most of what applies for Redirect agent apply to the Realm-based redirect proxy/server.
OK.
So agreed on 
   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent 
   [RFC6733], but instead by an application-aware Diameter node
   (Diameter server or proxy). 

The rest of the paragraph is:
   However, despite the change in executing
   role, the behaviour itself is a slight modification of the behaviour
   of a redirect agent as described in Section 2.8.3 of [RFC6733].

Proposal (for the second part of the paragraph):
   However, despite the change in executing
   role, the realm-based redirect proxy/server behaviour is only a slight modification of the behaviour
   of a redirect agent as described in Section 2.8.3 of [RFC6733].


Also, regarding the last point in the email, you should decide if you want to introduce redirecting server or realm-based redirecting server or realm-based redirect proxy/server
 in the terminology. Just be consistent throughout the doc.


 
3.
   An application can specify that realm-based redirection operates only
   on the initial message of a session, or on any message of a session.
 
"only the initial message" or "on any message of a session" = "on any message of a session", right?
Remove "only", that would make sense with the next sentence in the paragraph.
[LM] would it be: "operates either only on the initial message of a session, or on any message of a session"
ok.
 
Same remark for the first paragraph in 3.2.1
 
4.
I thought about this use case:
   "consider the case where an operator has offered a specific
   service but no longer wishes to do so.  The operator has arranged for
   an alternative domain to provide the service."
Don't we need "Redirect-Max-Cache-Time" = "forever"?
Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is not present?
I could not find a definitive answer in the draft or in RFC 6733 
[LM] A redirection is always  a "temporary" info so the Max-Cache-Time is always present when a cache is created.
   The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
   This AVP MUST be present in answer messages whose 'E' bit is set,
   whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and
   whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon as you need to cache the info).
About the "forever", you can't say more than "keep the info cached for 136 years". So it is not "forever" but not too bad.
Not that bad indeed. If this is common practice to put pretty high number in Redirect-Max-Cache-Time, fine then.
.
 
5.
      If the redirected request contained a Destination-Host AVP, that
      AVP is ignored by the redirecting server.
 
Pay attention that you update RFC 6733
 
Proposal
      If the redirected request contains a Result-Code AVP set to
      DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, 
      that Destination-Host AVP MUST be ignored by the redirecting server.
 
Or 
      When a directed request contains a Result-Code AVP set to
      DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP
      content MUST be ignored by the redirecting server.
[LM] I think that "redirected" is misleading here as "redirected request" is used as "the request to be redirected".
The clarification here is about the fact that as per RFC6733, a request containing a Destination-Host cannot be rerouted:

   An example of a case where it is not possible to

   forward the message to an alternate server is when the message has a

   fixed destination, and the unavailable peer is the message's final

   destination (see Destination-Host AVP).  Such an error requires that

   the agent return an answer message with the 'E' bit set and the

   Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

 
About ignoring the Destination-Host, I think that it is not possible to say "MUST be ignored" as it will be application-dependent. For instance, one criterion for realm based redirection can be: "only for initial session request when no Destination-host is present". We could say: "The Realm-based redirection MAY be applied even if a Destination-Host AVP is present in the request, depending on the operator-based policy."
ok
 
6.
   A proxy conforming to this specification that receives an answer
   message with the Result-Code AVP set to
   DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the
   original request to a server in a realm identified by a Redirect-
   Realm AVP instance in the answer message, or MAY simply forward the
   message toward the client. 
 
It MUST do one of the two things, I guess. Otherwise, doing nothing is also a valid option according to the text.
Please mention it.
[LM] Any proxy can do something but a proxy conforming to this specification MUST attempt to reroute… and if it fails, MUST forward the indication to the client.
Please change the text then.
 
 
7.
Section 3.2.2
And what if all point of the procedure fail, for all realms, what should happen?
DIAMETER_REDIRECT_INDICATION to the client?
[LM] yes. See above.
 
 
Editorial
- Redirect agent versus redirect agent
- Redirecting Server is a new term AFAICT, and is not really defined (even if we can guess).
Is this intentional?
[LM] should be introduced in the def section.
thanks and regards, Benoit
 
 
Regards, Benoit

 

 

_________________________________________________________________________________________________________________________

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

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

--------------020108080506050806000400-- From bclaise@cisco.com Fri Jul 26 09:16:16 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 1DD1411E8114 for ; Fri, 26 Jul 2013 09:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lwZdfXdmqwS for ; Fri, 26 Jul 2013 09:16:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCD411E810C for ; Fri, 26 Jul 2013 09:16:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6QGG5As001423; Fri, 26 Jul 2013 18:16:05 +0200 (CEST) Received: from [10.61.111.237] (dhcp-10-61-111-237.cisco.com [10.61.111.237]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6QGFZkn025653; Fri, 26 Jul 2013 18:15:45 +0200 (CEST) Message-ID: <51F27999.6000502@cisco.com> Date: Fri, 26 Jul 2013 15:28:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Taylor References: <51EE7BBE.1050804@cisco.com> <51EF07E5.7070300@cisco.com> <19162_1374674665_51EFDEE9_19162_49_1_6B7134B31289DC4FAF731D844122B36E231E29@PEXCVZYM13.corporate.adroot.infra.ftgroup> <51F03F1B.1010702@gmail.com> In-Reply-To: <51F03F1B.1010702@gmail.com> Content-Type: multipart/alternative; boundary="------------040601000907050109010807" Cc: dime mailing list Subject: Re: [Dime] AD review of draft-ietf-dime-realm-based-redirect 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, 26 Jul 2013 16:16:16 -0000 This is a multi-part message in MIME format. --------------040601000907050109010807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tom, > Thanks for picking this up, Lionel. I started to work on a response last > night but got distracted by other work. Comments below marked with > [PTT]. Parts where I have nothing to add to Lionel's responses are > omitted. > > Tom Taylor > > On 24/07/2013 10:04 AM, lionel.morand@orange.com wrote: >> Hi Benoit, >> >> please see below. >> >> Regards, >> >> Lionel (as Doc Shepherd) >> > ... >> >> But then, if it doesn't apply to a Redirect Agent, then why do we >> have this paragraph >> >> However, despite the change in executing >> >> role, the behaviour itself is a slight modification of the behaviour >> >> of a redirect agent as described in Section 2.8.3 of >> [RFC6733]. >> >> [LM]My understanding is to point out that the role of the Realm-based >> redirect proxy/server is very close to the behavior of a "regular" >> redirect agent, and therefore most of what applies for Redirect agent >> apply to the Realm-based redirect proxy/server. >> > [PTT] Agreed. The purpose of this text is just to give the reader a > point of reference for what follows. See my reply to Lionel. > >> >> >> 3. >> >> An application can specify that realm-based redirection operates >> only >> >> on the initial message of a session, or on any message of a session. >> >> >> >> "only the initial message" or "on any message of a session" = "on any >> message of a session", right? >> >> Remove "only", that would make sense with the next sentence in the >> paragraph. >> >> [LM] would it be: "operates either only on the initial message of a >> session, or on any message of a session" >> >> >> >> Same remark for the first paragraph in 3.2.1 >> > [PTT] I think what I mean to say in Section 2 is: "only on complete > sessions beginning with the initial message, or on every message > within the application, even if earlier messages of the same session > were not redirected. This distinction matters only when realm-based > redirection is first initiated." Then in Section 3.1.2 I would repeat > the first sentence. Ah, ok. I understand why you want that distinction. Please clarify the text >> >> >> 4. >> >> I thought about this use case: >> >> "consider the case where an operator has offered a specific >> >> service but no longer wishes to do so. The operator has arranged >> for >> >> an alternative domain to provide the service." >> >> Don't we need "Redirect-Max-Cache-Time" = "forever"? >> >> Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is >> not present? >> >> I could not find a definitive answer in the draft or in RFC 6733 >> >> [LM] A redirection is always a "temporary" info so the >> Max-Cache-Time is always present when a cache is created. >> >> The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type >> Unsigned32. >> >> This AVP MUST be present in answer messages whose 'E' bit is set, >> >> whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and >> >> whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon >> as you need to cache the info). >> >> About the "forever", you can't say more than "keep the info cached >> for 136 years". So it is not "forever" but not too bad. >> >> > [PTT] No action here? Don't think so. You might want to have a sentence explaining how the "forever" use case is done. Up to you. > >> >> 5. >> >> If the redirected request contained a Destination-Host AVP, that >> >> AVP is ignored by the redirecting server. >> >> >> >> Pay attention that you update RFC 6733 >> >> >> >> Proposal >> >> If the redirected request contains a Result-Code AVP set to >> >> DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP, >> >> that Destination-Host AVP MUST be ignored by the redirecting server. >> >> >> >> Or >> >> When a directed request contains a Result-Code AVP set to >> >> DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP >> >> content MUST be ignored by the redirecting server. >> >> [LM] I think that "redirected" is misleading here as "redirected >> request" is used as "the request to be redirected". >> >> The clarification here is about the fact that as per RFC6733, a >> request containing a Destination-Host cannot be rerouted: An example >> of a case where it is not possible to forward the message to an >> alternate server is when the message has a fixed destination, and the >> unavailable peer is the message's final destination (see >> Destination-Host AVP). Such an error requires that the agent return >> an answer message with the 'E' bit set and the Result-Code AVP set to >> DIAMETER_UNABLE_TO_DELIVER. >> >> >> >> About ignoring the Destination-Host, I think that it is not possible >> to say "MUST be ignored" as it will be application-dependent. For >> instance, one criterion for realm based redirection can be: "only for >> initial session request when no Destination-host is present". We >> could say: "The Realm-based redirection MAY be applied even if a >> Destination-Host AVP is present in the request, depending on the >> operator-based policy." >> >> > [PTT] I like that latter formulation. Fine. > >> >> 6. >> >> A proxy conforming to this specification that receives an answer >> >> message with the Result-Code AVP set to >> >> DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the >> >> original request to a server in a realm identified by a Redirect- >> >> Realm AVP instance in the answer message, or MAY simply forward the >> >> message toward the client. >> >> >> >> It MUST do one of the two things, I guess. Otherwise, doing nothing >> is also a valid option according to the text. >> >> Please mention it. >> >> [LM] Any proxy can do something but a proxy conforming to this >> specification MUST attempt to reroute... and if it fails, MUST >> forward the indication to the client. >> > [PTT] OK, I'll rephrase. >> >> >> >> 7. >> >> Section 3.2.2 >> >> And what if all point of the procedure fail, for all realms, what >> should happen? >> >> DIAMETER_REDIRECT_INDICATION to the client? >> >> [LM] yes. See above. >> >> > [PTT] No action? This would be solved by: [LM] Any proxy can do something but a proxy conforming to this specification MUST attempt to reroute... and if it fails, MUST forward the indication to the client. >> >> >> >> Editorial >> >> - Redirect agent versus redirect agent >> >> - Redirecting Server is a new term AFAICT, and is not really defined >> (even if we can guess). >> >> Is this intentional? >> >> [LM] should be introduced in the def section. >> >> > [PTT] OK >> > ... > > Regards, Benoit --------------040601000907050109010807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Tom,
Thanks for picking this up, Lionel. I started to work on a response last
night but got distracted by other work. Comments below marked with [PTT]. Parts where I have nothing to add to Lionel's responses are omitted.

Tom Taylor

On 24/07/2013 10:04 AM, lionel.morand@orange.com wrote:
Hi Benoit,

please see below.

Regards,

Lionel (as Doc Shepherd)

...

But then, if it doesn't apply to a Redirect Agent, then why do we
have this paragraph

However, despite the change in executing

role, the behaviour itself is a slight modification of the behaviour

of a redirect agent as described in Section 2.8.3 of
[RFC6733]<http://tools.ietf.org/html/rfc6733#section-2.8.3>.

[LM]My understanding is to point out that the role of the Realm-based
redirect proxy/server is very close to the behavior of a "regular"
redirect agent, and therefore most of what applies for Redirect agent
apply to the Realm-based redirect proxy/server.

[PTT] Agreed. The purpose of this text is just to give the reader a point of reference for what follows.
See my reply to Lionel.



3.

An application can specify that realm-based redirection operates
only

on the initial message of a session, or on any message of a session.



"only the initial message" or "on any message of a session" = "on any
message of a session", right?

Remove "only", that would make sense with the next sentence in the
paragraph.

[LM] would it be: "operates either only on the initial message of a
session, or on any message of a session"



Same remark for the first paragraph in 3.2.1

[PTT] I think what I mean to say in Section 2 is: "only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated." Then in Section 3.1.2 I would repeat the first sentence.
Ah, ok. I understand why you want that distinction. Please clarify the text


4.

I thought about this use case:

"consider the case where an operator has offered a specific

service but no longer wishes to do so.  The operator has arranged
for

an alternative domain to provide the service."

Don't we need "Redirect-Max-Cache-Time" = "forever"?

Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is
not present?

I could not find a definitive answer in the draft or in RFC 6733

[LM] A redirection is always  a "temporary" info so the
Max-Cache-Time is always present when a cache is created.

The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type
Unsigned32.

This AVP MUST be present in answer messages whose 'E' bit is set,

whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and

whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon
as you need to cache the info).

About the "forever", you can't say more than "keep the info cached
for 136 years". So it is not "forever" but not too bad.


[PTT] No action here?
Don't think so.
You might want to have a sentence explaining how the "forever" use case is done. Up to you.


5.

If the redirected request contained a Destination-Host AVP, that

AVP is ignored by the redirecting server.



Pay attention that you update RFC 6733



Proposal

If the redirected request contains a Result-Code AVP set to

DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP,

that Destination-Host AVP MUST be ignored by the redirecting server.



Or

When a directed request contains a Result-Code AVP set to

DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP

content MUST be ignored by the redirecting server.

[LM] I think that "redirected" is misleading here as "redirected
request" is used as "the request to be redirected".

The clarification here is about the fact that as per RFC6733, a
request containing a Destination-Host cannot be rerouted: An example
of a case where it is not possible to forward the message to an
alternate server is when the message has a fixed destination, and the
unavailable peer is the message's final destination (see
Destination-Host AVP).  Such an error requires that the agent return
an answer message with the 'E' bit set and the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER.



About ignoring the Destination-Host, I think that it is not possible
to say "MUST be ignored" as it will be application-dependent. For
instance, one criterion for realm based redirection can be: "only for
initial session request when no Destination-host is present". We
could say: "The Realm-based redirection MAY be applied even if a
Destination-Host AVP is present in the request, depending on the
operator-based policy."


[PTT] I like that latter formulation.
Fine.


6.

A proxy conforming to this specification that receives an answer

message with the Result-Code AVP set to

DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the

original request to a server in a realm identified by a Redirect-

Realm AVP instance in the answer message, or MAY simply forward the

message toward the client.



It MUST do one of the two things, I guess. Otherwise, doing nothing
is also a valid option according to the text.

Please mention it.

[LM] Any proxy can do something but a proxy conforming to this
specification MUST attempt to reroute... and if it fails, MUST
forward the indication to the client.

[PTT] OK, I'll rephrase.



7.

Section 3.2.2

And what if all point of the procedure fail, for all realms, what
should happen?

DIAMETER_REDIRECT_INDICATION to the client?

[LM] yes. See above.


[PTT] No action?
This would be solved by:
[LM] Any proxy can do something but a proxy conforming to this
specification MUST attempt to reroute... and if it fails, MUST
forward the indication to the client.



Editorial

- Redirect agent versus redirect agent

- Redirecting Server is a new term AFAICT, and is not really defined
(even if we can guess).

Is this intentional?

[LM] should be introduced in the def section.


[PTT] OK

...


Regards, Benoit
--------------040601000907050109010807-- From bclaise@cisco.com Sat Jul 27 08:38: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 E31FC21F9A13 for ; Sat, 27 Jul 2013 08:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.402 X-Spam-Level: X-Spam-Status: No, score=-10.402 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDSoIPbQtvMY for ; Sat, 27 Jul 2013 08:38:28 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3237321F8F4D for ; Sat, 27 Jul 2013 08:38:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6RFcEGV011699; Sat, 27 Jul 2013 17:38:14 +0200 (CEST) Received: from [10.61.214.14] ([10.61.214.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6RFbGCH000470; Sat, 27 Jul 2013 17:37:33 +0200 (CEST) Message-ID: <51F3E910.2080603@cisco.com> Date: Sat, 27 Jul 2013 17:36:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ben Campbell References: <51E5153F.3070101@cisco.com> <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> <51EBE991.3020609@cisco.com> <6FEAA094-F6B9-43DE-B997-AD5A85D55EB9@nostrum.com> In-Reply-To: <6FEAA094-F6B9-43DE-B997-AD5A85D55EB9@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, dime mailing list Subject: Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 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: Sat, 27 Jul 2013 15:38:34 -0000 Hi Ben, [not sure if that email was actually sent. Resending] > Hi Benoit, > > Do I read correctly that this particular issue requires no further action? I checked with the document shepherd, and you are right. No further action required on this issue. Please post a draft with the other agreed changes, and I'll progress the document Regards, Benoit > > A few more comments inline: > > On Jul 21, 2013, at 9:00 AM, Benoit Claise wrote: > >> On 19/07/2013 23:09, Ben Campbell wrote: > [...] > >>> On Jul 16, 2013, at 8:28 AM, Eric McMurry >>> wrote: >>> >>>> ah, thanks for catching that. Ben and I had been discussing this but I see responding to it was lost in the shuffle. My apologies. >>>> >>>> The definition uses the term resources, which could include a number of things. For the case where insufficient bandwidth would prevent overload, I think that would only be true for a very simple topology. With multiple connections to multiple elements, agents, shared backend resources, or any other more complex topologies, bandwidth issues could indeed manifest into overload issues that meet the definition. >>>> >>>> I suspect that I am not understanding your point fully though. Perhaps Ben can take a stab if I am not making sense. >>>> >>>> >>> I think the issue may be that we never meant for "resources" to necessarily mean "local resources". For example, an agent could itself become overloaded because it's not getting responses from an upstream server. This could be simple because the downstream view of the server appears overloaded in aggregate to downstream clients. (This is very close to your idea of "system" overload, I think.) But the agent could also suffer truly local overload due to queues or memory filling up, the need to retransmit requests, etc. >>> >>> For the non-agent case, a server might depend on a remote database. If network congestion causes responses from the database server to be lost or slow down, the Diameter server can become overloaded. >>> >>> Would it help if we added a note to point out that the mentioned "resources" do not necessarily have to be local to the Diameter node? >>> >> I was able to narrow my source of confusion to a very specific point: what is an upstream diameter node? >> I took this "overload" definition: >> Overload occurs when an element, such as a Diameter server or agent, >> has insufficient resources to successfully process all of the traffic >> >> it is receiving. >> Then I took this sentence: >> External resources can include upstream Diameter nodes; for example, >> a Diameter agent can become effectively overloaded if one or more >> upstream nodes are overloaded. While overload is not the same thing >> as network congestion, network congestion can reduce a Diameter nodes >> ability to process and respond to requests, thus contributing to >> overload. >> >> In my mind, I saw a picture like this: >> >> Overloaded >> Upstream >> Diameter Diameter >> Node Node >> -------------------->---------X >> request >> >> So I was thinking: the Diameter node (on the right, on the drawing) didn't receive the request. So according to the definition, it can't be overloaded. > I agree that the node on the right is not overloaded in this example. But if the one on the left is an agent, the fact that transactions are failing between it and the node on the right may reduce it's ability to handle inbound requests from clients. > >> I guess that you had a picture like this in mind. >> Overloaded >> Upstream >> Diameter Diameter >> Node Node >> --------------------> request >> X<---------- (*) >> >> (*) the reply never arrived because the Overloaded Upstream Diameter Node is well ... overloaded > That is one possible case. A particularly bad one, even, since the node on the left is likely to start retrying requests. > > Another example would be when a node depends on a non-Diameter remote resource. Imagine the same picture as the previous one, but the node on the right is a database server. If there's network congestion between the Diameter node and the database server, the Diameter node may not be able to operate at normal capacity. > >> After checking "Upstream" in RFC 6733, we're should be fine. >> >> Figure 7 provides an example of a message forwarded upstream by a >> Diameter relay. >> >> +---------+ 1. Request +---------+ 2. Request +---------+ >> | Access |------------>|Diameter |------------>|Diameter | >> | | | | | Home | >> | Device |<------------| Relay |<------------| Server | >> +---------+ 4. Answer +---------+ 3. Answer +---------+ >> (Missing AVP) (Missing AVP) >> >> My confusion. sorry. > No Problem--It seems like 6733 uses "upstream" and "downstream" differently than I am used to. (Same with "client" and "server"). > > Thanks! > > Ben. > > > From internet-drafts@ietf.org Sun Jul 28 22:29: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 3FC4A21F9F08; Sun, 28 Jul 2013 22:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yHln9uP6t2u; Sun, 28 Jul 2013 22:29:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF15821F9130; Sun, 28 Jul 2013 22:29:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729052919.32173.74212.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 22:29:19 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 05:29:20 -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-10.txt Pages : 27 Date : 2013-07-28 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 4 are not sufficient for this purpose. This document describes the limitations of the existing mechanisms in Section 5. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From emcmurry@computer.org Sun Jul 28 22:32:21 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 6472021F9FE5 for ; Sun, 28 Jul 2013 22:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zCavjHlNT3j for ; Sun, 28 Jul 2013 22:32:16 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE021F9FE1 for ; Sun, 28 Jul 2013 22:32:16 -0700 (PDT) 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 1V3g48-0002jc-1v; Mon, 29 Jul 2013 05:32:16 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id D692ED5B1D7; Mon, 29 Jul 2013 00:32:13 -0500 (CDT) 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: U2FsdGVkX19u2T4exj885BGwqu76jxf/9T5AqAuKIAo= 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 Loc3rfW44m_x; Mon, 29 Jul 2013 00:32:13 -0500 (CDT) Received: from [192.168.13.6] (unknown [192.168.13.6]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 6FF68D5B1C9; Mon, 29 Jul 2013 00:32:10 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <51F3E910.2080603@cisco.com> Date: Mon, 29 Jul 2013 07:32:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F64EE48-0B07-4C59-8A5B-46B66C0CE3C3@computer.org> References: <51E5153F.3070101@cisco.com> <7FC7978E-7A8B-4874-AC96-CEFD304B15E9@computer.org> <51EBE991.3020609@cisco.com> <6FEAA094-F6B9-43DE-B997-AD5A85D55EB9@nostrum.com> <51F3E910.2080603@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1508) Cc: dime mailing list , draft-ietf-dime-overload-reqs.all@tools.ietf.org Subject: Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9 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, 29 Jul 2013 05:32:21 -0000 Hi Benoit, done: URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-10.txt Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-10 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-10 Thanks again for your help with this. Eric On Jul 27, 2013, at 17:36 , Benoit Claise wrote: > Hi Ben, >=20 > [not sure if that email was actually sent. Resending] >=20 >> Hi Benoit, >>=20 >> Do I read correctly that this particular issue requires no further = action? > I checked with the document shepherd, and you are right. No further = action required on this issue. > Please post a draft with the other agreed changes, and I'll progress = the document >=20 > Regards, Benoit >>=20 >> A few more comments inline: >>=20 >> On Jul 21, 2013, at 9:00 AM, Benoit Claise wrote: >>=20 >>> On 19/07/2013 23:09, Ben Campbell wrote: >> [...] >>=20 >>>> On Jul 16, 2013, at 8:28 AM, Eric McMurry >>>> wrote: >>>>=20 >>>>> ah, thanks for catching that. Ben and I had been discussing this = but I see responding to it was lost in the shuffle. My apologies. >>>>>=20 >>>>> The definition uses the term resources, which could include a = number of things. For the case where insufficient bandwidth would = prevent overload, I think that would only be true for a very simple = topology. With multiple connections to multiple elements, agents, = shared backend resources, or any other more complex topologies, = bandwidth issues could indeed manifest into overload issues that meet = the definition. >>>>>=20 >>>>> I suspect that I am not understanding your point fully though. = Perhaps Ben can take a stab if I am not making sense. >>>>>=20 >>>>>=20 >>>> I think the issue may be that we never meant for "resources" to = necessarily mean "local resources". For example, an agent could itself = become overloaded because it's not getting responses from an upstream = server. This could be simple because the downstream view of the server = appears overloaded in aggregate to downstream clients. (This is very = close to your idea of "system" overload, I think.) But the agent could = also suffer truly local overload due to queues or memory filling up, the = need to retransmit requests, etc. >>>>=20 >>>> For the non-agent case, a server might depend on a remote database. = If network congestion causes responses from the database server to be = lost or slow down, the Diameter server can become overloaded. >>>>=20 >>>> Would it help if we added a note to point out that the mentioned = "resources" do not necessarily have to be local to the Diameter node? >>>>=20 >>> I was able to narrow my source of confusion to a very specific = point: what is an upstream diameter node? >>> I took this "overload" definition: >>> Overload occurs when an element, such as a Diameter server or = agent, >>> has insufficient resources to successfully process all of the = traffic >>>=20 >>> it is receiving. >>> Then I took this sentence: >>> External resources can include upstream Diameter nodes; for = example, >>> a Diameter agent can become effectively overloaded if one or more >>> upstream nodes are overloaded. While overload is not the same = thing >>> as network congestion, network congestion can reduce a Diameter = nodes >>> ability to process and respond to requests, thus contributing to >>> overload. >>>=20 >>> In my mind, I saw a picture like this: >>>=20 >>> Overloaded >>> Upstream >>> Diameter = Diameter >>> Node = Node >>> -------------------->---------X >>> request >>>=20 >>> So I was thinking: the Diameter node (on the right, on the drawing) = didn't receive the request. So according to the definition, it can't be = overloaded. >> I agree that the node on the right is not overloaded in this example. = But if the one on the left is an agent, the fact that transactions are = failing between it and the node on the right may reduce it's ability to = handle inbound requests from clients. >>=20 >>> I guess that you had a picture like this in mind. >>> = Overloaded >>> = Upstream >>> Diameter = Diameter >>> Node = Node >>> = --------------------> request >>> = X<---------- (*) >>>=20 >>> (*) the reply never arrived because the Overloaded Upstream Diameter = Node is well ... overloaded >> That is one possible case. A particularly bad one, even, since the = node on the left is likely to start retrying requests. >>=20 >> Another example would be when a node depends on a non-Diameter remote = resource. Imagine the same picture as the previous one, but the node on = the right is a database server. If there's network congestion between = the Diameter node and the database server, the Diameter node may not be = able to operate at normal capacity. >>=20 >>> After checking "Upstream" in RFC 6733, we're should be fine. >>>=20 >>> Figure 7 provides an example of a message forwarded upstream by a >>> Diameter relay. >>>=20 >>> +---------+ 1. Request +---------+ 2. Request +---------+ >>> | Access |------------>|Diameter |------------>|Diameter | >>> | | | | | Home | >>> | Device |<------------| Relay |<------------| Server | >>> +---------+ 4. Answer +---------+ 3. Answer +---------+ >>> (Missing AVP) (Missing AVP) >>>=20 >>> My confusion. sorry. >> No Problem--It seems like 6733 uses "upstream" and "downstream" = differently than I am used to. (Same with "client" and "server"). >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >>=20 >=20 From susan.shishufeng@huawei.com Sun Jul 28 23:45: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 C302321F9F9D for ; Sun, 28 Jul 2013 23:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[AWL=-2.045, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPMQrosAmXb0 for ; Sun, 28 Jul 2013 23:45:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1448721F9FC3 for ; Sun, 28 Jul 2013 23:45:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATW57159; Mon, 29 Jul 2013 06:45:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 07:45:33 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 07:45:37 +0100 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.56]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 14:45:25 +0800 From: "Shishufeng (Susan)" To: Ben Campbell , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: AQHOibVnYJHVtWC8D0ORIz71Bpq75Zl7NILA Date: Mon, 29 Jul 2013 06:45:24 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> In-Reply-To: <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 29 Jul 2013 06:45:55 -0000 SGkgQmVuLCBFcmljLA0KDQpDb21pbmcgYmFjayB0byB0aGUgaW1wbGljaXQgb3IgZGVmYXVsdCBT Y29wZSBpc3N1ZS4NCg0KV2hhdGV2ZXIgaXQgaXMgY2FsbGVkIGFzICJpbXBsaWNpdCIgb3IgImRl ZmF1bHQiLCBteSBpbnRlbnRpb24gd2FzIHRoYXQgZm9yIDNHUFAgYXBwbGljYXRpb25zLCBhdCBs ZWFzdCBlLmcuIGZvciBTNmEvUzZkLCB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgc3VjaCBhbiBl eHBsaWNpdCBTY29wZSBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdGhlICJzY29wZSIgZm9yIHdoaWNo IHRoZSBvdmVybG9hZCBpbmZvcm1hdGlvbiBhcHBsaWVzLg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9m IHRoZSB0d28gd29yZGluZyBpbiB0aGUgY29udGV4dCBoZXJlIGFyZSB2ZXJ5IHNpbWlsYXIsIGJ1 dCBpZiB3ZSBoYXZlIHRvIGRpZmZlcmVudGlhdGUgdGhlbSwgImltcGxpY2l0IiBpcyBtb3JlIHBy b3BlciB0byBiZSB1c2VkIGZvciB0aGUgY2FzZSB3ZSBhcmUgYWRkcmVzc2luZywgd2hpY2ggbWVh bnMgdGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIHN1Y2ggYSBTY29wZSBkZWZpbmVkLCB0aGUgb3Zl cmxvYWQgaW5mb3JtYXRpb24gYXBwbGllcyBpbXBsaWNpdGx5IHRvIHRoZSBzY29wZSBpbXBsaWVk IGJ5IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UuDQoNCkluIHRoZSBj bGF1c2UgNS4yLjMgZm9yIGRlZmluaXRpb24gb2YgT3ZlcmxvYWQgQVZQIGluIHRoZSAiRGlhbWV0 ZXIgT3ZlcmxvYWQgQXJjaGl0ZWN0dXJlIGFuZCBJbmZvcm1hdGlvbiBNb2RlbCIgZHJhZnQsIHRo ZSBsYXN0IHNlbnRlbmNlIHNheXM6DQoNCiAgIFRoZSBpbmNyZWFzZSBhbmQgZGVjcmVhc2Ugb2Yg dGhlIHNlbmRpbmcgcmF0ZSByZWZlcnMgdG8gbmV3IHJlcXVlc3RzDQogICB0byB0aGUgc2FtZSBy ZWFsbSBhbmQgdGhlIHNhbWUgYXBwbGljYXRpb24gSUQgYXMgdGhlIG1lc3NhZ2UgY2FycnlpbmcN CiAgIHRoZSBvdmVybG9hZCBpbmZvcm1hdGlvbi4NCg0Kd2hpY2ggbWF5IGltcGx5IHN1Y2ggYW4g aW1wbGljaXQgc2NvcGUgd2UgYXJlIHRhbGtpbmcgYWJvdXQuIEhhbm5lcyBtYXkgcHJvdmlkZSBo aXMgaW50ZXJwcmV0YXRpb24uDQoNCkJlc3QgUmVnYXJkcywNClN1c2FuDQoNCi0tLS0t08q8/tSt vP4tLS0tLQ0Kt6K8/sjLOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dIA0K t6LLzcqxvOQ6IDIwMTPE6jfUwjI2yNUgNjoyMw0KytW8/sjLOiBUUk9UVElOLCBKRUFOLUpBQ1FV RVMgKEpFQU4tSkFDUVVFUykNCrOty806IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBkaW1lQGlldGYu b3JnOyBCRVJSWSwgTmlnZWwgKE5pZ2VsKTsgQmVzc2lzLCBUaGllcnJ5IChUaGllcnJ5KQ0K1vfM 4jogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxpY2l0IiBTY29w ZQ0KDQpIaSBKSmFxdWVzLCBzZWUgY29tbWVudHMgaW5saW5lOg0KDQpPbiBKdWwgMjQsIDIwMTMs IGF0IDc6NTkgQU0sICJUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykiIDxqZWFu LWphY3F1ZXMudHJvdHRpbkBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KDQo+IA0KPiBEZWFy IGFsbA0KPiANCj4gSSBoZXJlYWZ0ZXIgYWRkIHNvbWUgY29tbWVudHMgb24gdHdvIG9uZXMgbWFk ZSBpbiBwcmV2aW91cyBtYWlscy4NCj4gDQo+IC0gdGhlcmUgd2FzIHRoZSBjb21tZW50ICIgSSdt IG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IHRoZSBpbXBsaWNpdCBzY29wZSBpcyBpbiBIYW5u ZXMncyBkcmFmdCIuLiAgSSBhZ3JlZSBpdCB3b3VsZCBiZSBnb29kIEhhbm5lcyB0byBjbGFyaWZ5 IGhpcyBuZXcgcHJvcG9zYWwuIEZyb20gbXkgb3duIHJlYWRpbmcgaW4gZHJhZnQtdHNjaG9mZW5p Zy1kaW1lLW92ZXJsb2FkLXBpZ2d5YmFja2luZyBpbiAgMy4yOg0KPiAgIC4uLiB0aGUgRGlhbWV0 ZXINCj4gICBzZXJ2ZXIgKG9yIGEgcHJveHksIC4uLi4pIG1heSBkZWNpZGUgdG8gY29tbXVuaWNh dGUgdG8gdGhlIERpYW1ldGVyDQo+ICAgY2xpZW50IHRvIHJlamVjdCBzb21lIG9yIGV2ZW4gYWxs IERpYW1ldGVyIHJlcXVlc3RzLiBUaGUgRGlhbWV0ZXINCj4gICBzZXJ2ZXIgZG9lcyBzbyBieSBh ZGRpbmcgdGhlIE92ZXJsb2FkLUluZm8gQVZQLCB3aGljaCBjb250YWlucyB0aGUNCj4gICBPdmVy bG9hZCBhbmQgdGhlIFBlcmlvZC1PZi1WYWxpZGl0eSBBVlAuDQo+IA0KPiBUaGVuIHRoZSBvdmVy bG9hZCBBVlAgaW5kaWNhdGVzIHRvIHRoZSBjbGllbnQgdGhlIGFtb3VudCBvZiB0cmFmZmljIHRv IGRlY3JlYXNlIG9yIHRvIGluY3JlYXNlLiBTbyBmcm9tIG15IHVuZGVyc3RhbmRpbmcsIGl0IGlz IHNpbWlsYXIgdG8gdGhlIGltcGxpY2l0IHNjb3BlIEkgaGF2ZSBkZXNjcmliZWQgYXMgdGhlIHBp Z2d5YmFja2VkIG92ZXJsb2FkIGluZm8gaXMgcmVsYXRlZCB0byB0aGUgbWVzc2FnZSB0cmFuc3Bv cnRpbmcgaXQsIGFuZCBpbiBjb25zZXF1ZW5jZSBkb2VzIG5vdCByZXF1aXJlIHRvIGluZGljYXRl IGFuIGV4cGxpY2l0IHNjb3BlLiANCg0KRG8gSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB0aGF0IHlv dSBhc3N1bWUgdGhlIHRyYWZmaWMgdGhhdCBzaG91bGQgYmUgcmVkdWNlZCBpcyB0aGUgc2V0IG9m IGZ1dHVyZSByZXF1ZXN0cyB0aGF0IGhhdmUgdGhlIHNhbWUgcmVhbG0sIGFwcGxpY2F0aW9uLUlk LCBhbmQgcGVyaGFwcyBkZXN0aW5hdGlvbi1ob3N0L29yaWdpbi1ob3N0IHRoYXQgbWF0Y2hlcyB0 aGF0IG9mIHRoZSBtZXNzYWdlIGNvbnRhaW5pbmcgdGhlIG92ZXJsb2FkIHJlcG9ydD8gSSBkb24n dCByZWNhbGwgc2VlaW5nIHRleHQgaW4gdGhlIGRyYWZ0IHRvIGluZGljYXRlIHRoYXQsIGJ1dCBt aWdodCBoYXZlIG1pc3NlZCBzb21ldGhpbmcuIChJZiBJIGRpZCwgcGxlYXNlIGRvbid0IGhlc2l0 YXRlIHRvIGVkdWNhdGUgbWUgOi0pICApDQoNCj4gSSBoYXZlIG90aGVyIHZpZXdzIG9uIHRoZSBj b250ZW50IG9mIHRoZSBvdmVybG9hZCBpbmZvIHdoZXJlICBJIGFtIGluIGZhdm91ciBvZiBhbiBv dmVybG9hZCBpbmZvIGluZGljYXRpbmcgYSAlIG9mIHRyYWZmaWMgcmVkdWN0aW9uIHRvIGJlIGFw cGxpZWQuIEkgYWxzbyBjb25zaWRlciB0aGUgb3Zlcmxhb2QgaW5mbyBpcyB1c2VkIGJ5IHRoZSB0 aHJvdHRsaW5nIGVudGl0eSB3aGljaCBtYXkgYmUgdGhlIGNsaWVudCBvciBhbiBpbnRlcm1lZGlh dGUgREEuIEhhbm5lcyBvbmx5IG1lbnRpb25zIHRoZSBjbGllbnQuDQoNClRoYXQgd291bGQgYmUg c2ltaWxhciB0byB3aGF0IGlzIGluIGRyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybCwgd2hl biB1c2VkIHdpdGggdGhlIGluY2x1ZGVkICJsb3NzIiBhbGdvcml0aG0sIHJpZ2h0PyAoaWdub3Jp bmcgZm9yIHRoZSBtb21lbnQgaXNzdWVzIG9mIGNyb3NzaW5nIG5vbi1zdXBwb3J0aW5nIGFnZW50 cykNCg0KPiANCj4gLSBhYm91dCB0aGUgY29tbWVudCAiZG8geW91IG1lYW4gYSBkZWZhdWx0PyAo dGhhdCBpcywgb25lIHRoYXQgYXBwbGllcyBpZiBubyBzY29wZSBpcyBleHBsaWNpdGx5IGluY2x1 ZGVkKT8iLiBUaGUgaW1wbGljaXQgc2NvcGUgSSBoYXZlIGRlc2NyaWJlZCBpcyBub3QgYSBkZWZh dWx0IHNjb3BlLCBpbiB0aGUgYWJvdmUgbWVhbmluZy4gSXQgaXMgaW1wbGljaXQgYmVjYXVzZSBp dCBhcHBsaWVzIHRvIHRoZSB0cmFmZmljIHRvIHdoaWNoIHRoZSBtZXNzYWdlIGNvbnZleWluZyB0 aGUgb3ZlcmxvYWQgaW5mbyBiZWxvbmdzLiBUaGlzIHNjb3BlIGlzIG5vdCBleGNsdXNpdmUgb2Yg b3RoZXIgc2NvcGVzLCBidXQgZm9yIHRoZSBtYW55IGNhc2VzIHRoYXQgaXQgY292ZXJzIGJ5IGl0 c2VsZiwgIEkgZG8gbm90IGZvcmVzZWUgIHRvIHVzZSBpdCBpbiBjb25qdW5jdGlvbiB3aXRoIG90 aGVycy4gQXMgbWVudGlvbmVkLCBJIHdvdWxkIGxpa2UgdG8ga25vdyB1c2UgY2FzZXMsIHRoYXQg dGhpcyBpbXBsaWNpdCBzY29wZSB3aWxsIG5vdCBjb3ZlciBhbmQgd2hpY2ggb3RoZXIgc2NvcGVz IG9yIGV4dGVuc2lvbnMgd291bGQgYmUgcmVxdWlyZWQuDQoNClRoZSBSb2FjaCBkcmFmdCBjdXJy ZW50bHkgaGFzIGEgIkNvbm5lY3Rpb24iIHNjb3BlIHRoYXQgdGFrZXMgaXQncyB2YWx1ZSBmcm9t IHRoZSBjb25uZWN0aW9uIG9uIHdoaWNoIHRoZSByZXBvcnQgYXJyaXZlZC4gSXQncyBhbiBleHBs aWNpdGx5IGluY2x1ZGVkIHNjb3BlLCBidXQgaXQncyB2YWx1ZSBpcyBpbXBsaWNpdC4gSXMgdGhh dCB0aGUgc29ydCBvZiB0aGluZyB5b3UgaGF2ZSBpbiBtaW5kLCBidXQgZm9yIGEgZGlmZmVyZW50 IHNldCBvZiBpbXBsaWNpdCB2YWx1ZXM/IFRoYXQgaXMsIHdlIGNvdWxkIGhhdmUgc29ydCBvZiBh ICJ0aGlzIHJlYWxtIGFuZCBhcHBsaWNhdGlvbiIgc2NvcGU/IFlvdSB3b3VsZCBleHBsaWNpdGx5 IGluY2x1ZGUgaXQsIGJ1dCB0aGUgcmVhbG0gYW5kIGFwcGxpY2F0aW9uLUlEIHZhbHVlcyB3b3Vs ZCBiZSBpbXBsaWVkIGJ5IHRoZSBtZXNzYWdlIGNvbnRlbnRzPw0KDQpUaGFua3MhDQoNCkJlbi4N Cg== From ben@nostrum.com Mon Jul 29 00:56:43 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 6A21221F9B9D for ; Mon, 29 Jul 2013 00:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSePmbNOThuD for ; Mon, 29 Jul 2013 00:56:42 -0700 (PDT) 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 71C4F21F9B8D for ; Mon, 29 Jul 2013 00:56:42 -0700 (PDT) Received: from dhcp-4241.meeting.ietf.org (dhcp-4241.meeting.ietf.org [130.129.66.65]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6T7uIxZ025597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 02:56:20 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> Date: Mon, 29 Jul 2013 09:56:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A0E23ED-8F51-41D6-ACD1-0A6896593D3A@nostrum.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com>! <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> To: "Shishufeng (Susan)" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 130.129.66.65 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 29 Jul 2013 07:56:43 -0000 On Jul 29, 2013, at 8:45 AM, "Shishufeng (Susan)" = wrote: > Hi Ben, Eric, >=20 > Coming back to the implicit or default Scope issue. >=20 > Whatever it is called as "implicit" or "default", my intention was = that for 3GPP applications, at least e.g. for S6a/S6d, there is no need = to have such an explicit Scope parameter to indicate the "scope" for = which the overload information applies. >=20 > My understanding of the two wording in the context here are very = similar, but if we have to differentiate them, "implicit" is more proper = to be used for the case we are addressing, which means there is no need = to have such a Scope defined, the overload information applies = implicitly to the scope implied by the information contained in the = message. I think we can define "default" to mean a scope used if nothing else is = specified, and "implicit" to mean the the receiver infers the scope = value(s) from the message, rather than having an explicit value = indicated in the scope. I think the scope you are asking for is = "implicit", and it might also be "default" (although I would still argue = that the best default, at least for adjacent peer connections, is = "connection"). >=20 > In the clause 5.2.3 for definition of Overload AVP in the "Diameter = Overload Architecture and Information Model" draft, the last sentence = says: >=20 > The increase and decrease of the sending rate refers to new requests > to the same realm and the same application ID as the message = carrying > the overload information. >=20 > which may imply such an implicit scope we are talking about. Hannes = may provide his interpretation. >=20 I agree with your interpretation. Apologies, I missed that on first = reading, and was looking for it in Hannes's mechanism draft instead of = the architecture draft. From jean-jacques.trottin@alcatel-lucent.com Mon Jul 29 01:07:24 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 273B721F9D92 for ; Mon, 29 Jul 2013 01:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3H4aPV8jXDz for ; Mon, 29 Jul 2013 01:07:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 98EBE21F9E28 for ; Mon, 29 Jul 2013 01:06:31 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6T86QgM011852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Jul 2013 03:06:28 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6T86QPM017472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 10:06:26 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.33]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 29 Jul 2013 10:06:26 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Ben Campbell Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: AQHOh66wGuip22BE/EGIiiTArSzZUplyMAiAgAGThNCAAhaDgIAFQ3QAgAAl1BA= Date: Mon, 29 Jul 2013 08:06:25 +0000 Message-ID: References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 29 Jul 2013 08:07:24 -0000 SGkgQmVuDQoNClRoZSBpbXBsaWNpdCBzY29wZSBJIHJlZmVyIHRvIChhcyB3ZWxsIGFzIFN1emFu KSBpcyBlZmZlY3RpdmVseSB0aGUgb25lIHJlbGF0ZWQgdG8gdGhlIGZsb3cgb2YgcmVxdWVzdHMg dGhhdCBtYXRjaGVzIHRoYXQgb2YgdGhlIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgb3ZlcmxvYWQg cmVwb3J0LiBJIHdvdWxkIGxpa2UgdGhpcyBzY29wZSBiZSBwYXJ0IG9mIHRoZSBzb2x1dGlvbiwg YnV0IHRoZSBjdXJyZW50IGRyYWZ0LCBhcyB5b3UgdW5kZXJsaW5lZCwgZG9lcyBub3QgcmVmZXIg dG8gdGhpcyBzY29wZS4gV2Ugd2lsbCBmdXJ0aGVyIGRpc2N1c3MgaXQgZHVyaW5nIHRoZSBJRVRG IDg3IG1lZXRpbmcuDQoNCkJlc3QgcmVnYXJkcw0KDQoNCkpKYWNxdWVzIA0KDQoNCi0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogU2hpc2h1ZmVuZyAoU3VzYW4pIFttYWlsdG86c3Vz YW4uc2hpc2h1ZmVuZ0BodWF3ZWkuY29tXSANCkVudm95w6nCoDogbHVuZGkgMjkganVpbGxldCAy MDEzIDA4OjQ1DQrDgMKgOiBCZW4gQ2FtcGJlbGw7IFRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVB Ti1KQUNRVUVTKQ0KQ2PCoDogRFJBR0UsIEtlaXRoIChLZWl0aCk7IGRpbWVAaWV0Zi5vcmc7IEJF UlJZLCBOaWdlbCAoTmlnZWwpOyBCZXNzaXMsIFRoaWVycnkgKFRoaWVycnkpDQpPYmpldMKgOiBS ZTogW0RpbWVdIERpYW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVsdCAiSW1wbGljaXQiIFNjb3BlDQoN CkhpIEJlbiwgRXJpYywNCg0KQ29taW5nIGJhY2sgdG8gdGhlIGltcGxpY2l0IG9yIGRlZmF1bHQg U2NvcGUgaXNzdWUuDQoNCldoYXRldmVyIGl0IGlzIGNhbGxlZCBhcyAiaW1wbGljaXQiIG9yICJk ZWZhdWx0IiwgbXkgaW50ZW50aW9uIHdhcyB0aGF0IGZvciAzR1BQIGFwcGxpY2F0aW9ucywgYXQg bGVhc3QgZS5nLiBmb3IgUzZhL1M2ZCwgdGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIHN1Y2ggYW4g ZXhwbGljaXQgU2NvcGUgcGFyYW1ldGVyIHRvIGluZGljYXRlIHRoZSAic2NvcGUiIGZvciB3aGlj aCB0aGUgb3ZlcmxvYWQgaW5mb3JtYXRpb24gYXBwbGllcy4NCg0KTXkgdW5kZXJzdGFuZGluZyBv ZiB0aGUgdHdvIHdvcmRpbmcgaW4gdGhlIGNvbnRleHQgaGVyZSBhcmUgdmVyeSBzaW1pbGFyLCBi dXQgaWYgd2UgaGF2ZSB0byBkaWZmZXJlbnRpYXRlIHRoZW0sICJpbXBsaWNpdCIgaXMgbW9yZSBw cm9wZXIgdG8gYmUgdXNlZCBmb3IgdGhlIGNhc2Ugd2UgYXJlIGFkZHJlc3NpbmcsIHdoaWNoIG1l YW5zIHRoZXJlIGlzIG5vIG5lZWQgdG8gaGF2ZSBzdWNoIGEgU2NvcGUgZGVmaW5lZCwgdGhlIG92 ZXJsb2FkIGluZm9ybWF0aW9uIGFwcGxpZXMgaW1wbGljaXRseSB0byB0aGUgc2NvcGUgaW1wbGll ZCBieSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSBtZXNzYWdlLg0KDQpJbiB0aGUg Y2xhdXNlIDUuMi4zIGZvciBkZWZpbml0aW9uIG9mIE92ZXJsb2FkIEFWUCBpbiB0aGUgIkRpYW1l dGVyIE92ZXJsb2FkIEFyY2hpdGVjdHVyZSBhbmQgSW5mb3JtYXRpb24gTW9kZWwiIGRyYWZ0LCB0 aGUgbGFzdCBzZW50ZW5jZSBzYXlzOg0KDQogICBUaGUgaW5jcmVhc2UgYW5kIGRlY3JlYXNlIG9m IHRoZSBzZW5kaW5nIHJhdGUgcmVmZXJzIHRvIG5ldyByZXF1ZXN0cw0KICAgdG8gdGhlIHNhbWUg cmVhbG0gYW5kIHRoZSBzYW1lIGFwcGxpY2F0aW9uIElEIGFzIHRoZSBtZXNzYWdlIGNhcnJ5aW5n DQogICB0aGUgb3ZlcmxvYWQgaW5mb3JtYXRpb24uDQoNCndoaWNoIG1heSBpbXBseSBzdWNoIGFu IGltcGxpY2l0IHNjb3BlIHdlIGFyZSB0YWxraW5nIGFib3V0LiBIYW5uZXMgbWF5IHByb3ZpZGUg aGlzIGludGVycHJldGF0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQpTdXNhbg0KDQotLS0tLemCruS7 tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVt LmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMjbml6UgNjoyMw0K5pS25Lu25Lq6OiBU Uk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykNCuaKhOmAgTogRFJBR0UsIEtlaXRo IChLZWl0aCk7IGRpbWVAaWV0Zi5vcmc7IEJFUlJZLCBOaWdlbCAoTmlnZWwpOyBCZXNzaXMsIFRo aWVycnkgKFRoaWVycnkpDQrkuLvpopg6IFJlOiBbRGltZV0gRGlhbWV0ZXIgT3ZlcmxvYWQgLSBE ZWZhdWx0ICJJbXBsaWNpdCIgU2NvcGUNCg0KSGkgSkphcXVlcywgc2VlIGNvbW1lbnRzIGlubGlu ZToNCg0KT24gSnVsIDI0LCAyMDEzLCBhdCA3OjU5IEFNLCAiVFJPVFRJTiwgSkVBTi1KQUNRVUVT IChKRUFOLUpBQ1FVRVMpIiA8amVhbi1qYWNxdWVzLnRyb3R0aW5AYWxjYXRlbC1sdWNlbnQuY29t PiB3cm90ZToNCg0KPiANCj4gRGVhciBhbGwNCj4gDQo+IEkgaGVyZWFmdGVyIGFkZCBzb21lIGNv bW1lbnRzIG9uIHR3byBvbmVzIG1hZGUgaW4gcHJldmlvdXMgbWFpbHMuDQo+IA0KPiAtIHRoZXJl IHdhcyB0aGUgY29tbWVudCAiIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW1w bGljaXQgc2NvcGUgaXMgaW4gSGFubmVzJ3MgZHJhZnQiLi4gIEkgYWdyZWUgaXQgd291bGQgYmUg Z29vZCBIYW5uZXMgdG8gY2xhcmlmeSBoaXMgbmV3IHByb3Bvc2FsLiBGcm9tIG15IG93biByZWFk aW5nIGluIGRyYWZ0LXRzY2hvZmVuaWctZGltZS1vdmVybG9hZC1waWdneWJhY2tpbmcgaW4gIDMu MjoNCj4gICAuLi4gdGhlIERpYW1ldGVyDQo+ICAgc2VydmVyIChvciBhIHByb3h5LCAuLi4uKSBt YXkgZGVjaWRlIHRvIGNvbW11bmljYXRlIHRvIHRoZSBEaWFtZXRlcg0KPiAgIGNsaWVudCB0byBy ZWplY3Qgc29tZSBvciBldmVuIGFsbCBEaWFtZXRlciByZXF1ZXN0cy4gVGhlIERpYW1ldGVyDQo+ ICAgc2VydmVyIGRvZXMgc28gYnkgYWRkaW5nIHRoZSBPdmVybG9hZC1JbmZvIEFWUCwgd2hpY2gg Y29udGFpbnMgdGhlDQo+ICAgT3ZlcmxvYWQgYW5kIHRoZSBQZXJpb2QtT2YtVmFsaWRpdHkgQVZQ Lg0KPiANCj4gVGhlbiB0aGUgb3ZlcmxvYWQgQVZQIGluZGljYXRlcyB0byB0aGUgY2xpZW50IHRo ZSBhbW91bnQgb2YgdHJhZmZpYyB0byBkZWNyZWFzZSBvciB0byBpbmNyZWFzZS4gU28gZnJvbSBt eSB1bmRlcnN0YW5kaW5nLCBpdCBpcyBzaW1pbGFyIHRvIHRoZSBpbXBsaWNpdCBzY29wZSBJIGhh dmUgZGVzY3JpYmVkIGFzIHRoZSBwaWdneWJhY2tlZCBvdmVybG9hZCBpbmZvIGlzIHJlbGF0ZWQg dG8gdGhlIG1lc3NhZ2UgdHJhbnNwb3J0aW5nIGl0LCBhbmQgaW4gY29uc2VxdWVuY2UgZG9lcyBu b3QgcmVxdWlyZSB0byBpbmRpY2F0ZSBhbiBleHBsaWNpdCBzY29wZS4gDQoNCkRvIEkgdW5kZXJz dGFuZCBjb3JyZWN0bHkgdGhhdCB5b3UgYXNzdW1lIHRoZSB0cmFmZmljIHRoYXQgc2hvdWxkIGJl IHJlZHVjZWQgaXMgdGhlIHNldCBvZiBmdXR1cmUgcmVxdWVzdHMgdGhhdCBoYXZlIHRoZSBzYW1l IHJlYWxtLCBhcHBsaWNhdGlvbi1JZCwgYW5kIHBlcmhhcHMgZGVzdGluYXRpb24taG9zdC9vcmln aW4taG9zdCB0aGF0IG1hdGNoZXMgdGhhdCBvZiB0aGUgbWVzc2FnZSBjb250YWluaW5nIHRoZSBv dmVybG9hZCByZXBvcnQ/IEkgZG9uJ3QgcmVjYWxsIHNlZWluZyB0ZXh0IGluIHRoZSBkcmFmdCB0 byBpbmRpY2F0ZSB0aGF0LCBidXQgbWlnaHQgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLiAoSWYgSSBk aWQsIHBsZWFzZSBkb24ndCBoZXNpdGF0ZSB0byBlZHVjYXRlIG1lIDotKSAgKQ0KDQo+IEkgaGF2 ZSBvdGhlciB2aWV3cyBvbiB0aGUgY29udGVudCBvZiB0aGUgb3ZlcmxvYWQgaW5mbyB3aGVyZSAg SSBhbSBpbiBmYXZvdXIgb2YgYW4gb3ZlcmxvYWQgaW5mbyBpbmRpY2F0aW5nIGEgJSBvZiB0cmFm ZmljIHJlZHVjdGlvbiB0byBiZSBhcHBsaWVkLiBJIGFsc28gY29uc2lkZXIgdGhlIG92ZXJsYW9k IGluZm8gaXMgdXNlZCBieSB0aGUgdGhyb3R0bGluZyBlbnRpdHkgd2hpY2ggbWF5IGJlIHRoZSBj bGllbnQgb3IgYW4gaW50ZXJtZWRpYXRlIERBLiBIYW5uZXMgb25seSBtZW50aW9ucyB0aGUgY2xp ZW50Lg0KDQpUaGF0IHdvdWxkIGJlIHNpbWlsYXIgdG8gd2hhdCBpcyBpbiBkcmFmdC1yb2FjaC1k aW1lLW92ZXJsb2FkLWN0cmwsIHdoZW4gdXNlZCB3aXRoIHRoZSBpbmNsdWRlZCAibG9zcyIgYWxn b3JpdGhtLCByaWdodD8gKGlnbm9yaW5nIGZvciB0aGUgbW9tZW50IGlzc3VlcyBvZiBjcm9zc2lu ZyBub24tc3VwcG9ydGluZyBhZ2VudHMpDQoNCj4gDQo+IC0gYWJvdXQgdGhlIGNvbW1lbnQgImRv IHlvdSBtZWFuIGEgZGVmYXVsdD8gKHRoYXQgaXMsIG9uZSB0aGF0IGFwcGxpZXMgaWYgbm8gc2Nv cGUgaXMgZXhwbGljaXRseSBpbmNsdWRlZCk/Ii4gVGhlIGltcGxpY2l0IHNjb3BlIEkgaGF2ZSBk ZXNjcmliZWQgaXMgbm90IGEgZGVmYXVsdCBzY29wZSwgaW4gdGhlIGFib3ZlIG1lYW5pbmcuIEl0 IGlzIGltcGxpY2l0IGJlY2F1c2UgaXQgYXBwbGllcyB0byB0aGUgdHJhZmZpYyB0byB3aGljaCB0 aGUgbWVzc2FnZSBjb252ZXlpbmcgdGhlIG92ZXJsb2FkIGluZm8gYmVsb25ncy4gVGhpcyBzY29w ZSBpcyBub3QgZXhjbHVzaXZlIG9mIG90aGVyIHNjb3BlcywgYnV0IGZvciB0aGUgbWFueSBjYXNl cyB0aGF0IGl0IGNvdmVycyBieSBpdHNlbGYsICBJIGRvIG5vdCBmb3Jlc2VlICB0byB1c2UgaXQg aW4gY29uanVuY3Rpb24gd2l0aCBvdGhlcnMuIEFzIG1lbnRpb25lZCwgSSB3b3VsZCBsaWtlIHRv IGtub3cgdXNlIGNhc2VzLCB0aGF0IHRoaXMgaW1wbGljaXQgc2NvcGUgd2lsbCBub3QgY292ZXIg YW5kIHdoaWNoIG90aGVyIHNjb3BlcyBvciBleHRlbnNpb25zIHdvdWxkIGJlIHJlcXVpcmVkLg0K DQpUaGUgUm9hY2ggZHJhZnQgY3VycmVudGx5IGhhcyBhICJDb25uZWN0aW9uIiBzY29wZSB0aGF0 IHRha2VzIGl0J3MgdmFsdWUgZnJvbSB0aGUgY29ubmVjdGlvbiBvbiB3aGljaCB0aGUgcmVwb3J0 IGFycml2ZWQuIEl0J3MgYW4gZXhwbGljaXRseSBpbmNsdWRlZCBzY29wZSwgYnV0IGl0J3MgdmFs dWUgaXMgaW1wbGljaXQuIElzIHRoYXQgdGhlIHNvcnQgb2YgdGhpbmcgeW91IGhhdmUgaW4gbWlu ZCwgYnV0IGZvciBhIGRpZmZlcmVudCBzZXQgb2YgaW1wbGljaXQgdmFsdWVzPyBUaGF0IGlzLCB3 ZSBjb3VsZCBoYXZlIHNvcnQgb2YgYSAidGhpcyByZWFsbSBhbmQgYXBwbGljYXRpb24iIHNjb3Bl PyBZb3Ugd291bGQgZXhwbGljaXRseSBpbmNsdWRlIGl0LCBidXQgdGhlIHJlYWxtIGFuZCBhcHBs aWNhdGlvbi1JRCB2YWx1ZXMgd291bGQgYmUgaW1wbGllZCBieSB0aGUgbWVzc2FnZSBjb250ZW50 cz8NCg0KVGhhbmtzIQ0KDQpCZW4uDQo= From emcmurry@computer.org Mon Jul 29 01:21: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 A182821F9E1E for ; Mon, 29 Jul 2013 01:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN8Yg46WDCTx for ; Mon, 29 Jul 2013 01:21:31 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id D56CB21F9D8A for ; Mon, 29 Jul 2013 01:21:18 -0700 (PDT) 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 1V3ihh-0003TJ-IZ; Mon, 29 Jul 2013 08:21:17 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 90C28D621FC; Mon, 29 Jul 2013 03:21:13 -0500 (CDT) 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: U2FsdGVkX1+CGsbbSpmbIAzy4hlbfh9bC8wmoiYh15Q= 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 oLHReLL-yuW9; Mon, 29 Jul 2013 03:21:13 -0500 (CDT) Received: from [192.168.13.6] (unknown [192.168.13.6]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id ACC8CD621E1; Mon, 29 Jul 2013 03:21:08 -0500 (CDT) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> Date: Mon, 29 Jul 2013 10:21:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9939898B-D6BB-4C83-BDE1-7F081375E781@computer.org> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> <26C84DF D55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> To: Shishufeng (Susan) X-Mailer: Apple Mail (2.1508) Cc: "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "dime@ietf.org" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 29 Jul 2013 08:21:37 -0000 Hi Susan, So, I think you are asking for a default scope (also a combined scope) = that uses implicit information. That is, you want a scope that applies = when there are no scopes called out (default) and you want it to use = information derived from other parts of the message it's piggybacked on = (implicit). I have no issue with the concepts here in general. I think picking = something specific to S6 may not be the best approach though. I started = trying to enumerate the scenarios and the useful scopes to go with them = to see if there was a default that would be useful in many cases, but = the number of ways that scopes would be used for various scenarios (not = just topologies, different scopes make sense for different things on the = same topology and connections) that there was no obvious answer. Ben has proposed the ability to specify an implicit value on scopes = where that makes sense (I forget his list, but I think there are several = scopes this could be done for). This makes sense and I think would = catch what you are after (as well as I understand it) for that part. = For the default part, I think more analysis is needed. I am not = convinced that there is anything reasonable here (there are too many = cases and defaults would be different for different = topologies/scenarios) or that having to put a scope on control = information is really an issue (this sounds like a few lines of code to = me). Thanks, Eric On Jul 29, 2013, at 8:45 , Shishufeng (Susan) = wrote: > Hi Ben, Eric, >=20 > Coming back to the implicit or default Scope issue. >=20 > Whatever it is called as "implicit" or "default", my intention was = that for 3GPP applications, at least e.g. for S6a/S6d, there is no need = to have such an explicit Scope parameter to indicate the "scope" for = which the overload information applies. >=20 > My understanding of the two wording in the context here are very = similar, but if we have to differentiate them, "implicit" is more proper = to be used for the case we are addressing, which means there is no need = to have such a Scope defined, the overload information applies = implicitly to the scope implied by the information contained in the = message. >=20 > In the clause 5.2.3 for definition of Overload AVP in the "Diameter = Overload Architecture and Information Model" draft, the last sentence = says: >=20 > The increase and decrease of the sending rate refers to new requests > to the same realm and the same application ID as the message = carrying > the overload information. >=20 > which may imply such an implicit scope we are talking about. Hannes = may provide his interpretation. >=20 > Best Regards, > Susan >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Ben Campbell [mailto:ben@nostrum.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C226=C8=D5 6:23 > =CA=D5=BC=FE=C8=CB: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > =B3=AD=CB=CD: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel = (Nigel); Bessis, Thierry (Thierry) > =D6=F7=CC=E2: Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hi JJaques, see comments inline: >=20 > On Jul 24, 2013, at 7:59 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >>=20 >> Dear all >>=20 >> I hereafter add some comments on two ones made in previous mails. >>=20 >> - there was the comment " I'm not sure I understand what the implicit = scope is in Hannes's draft".. I agree it would be good Hannes to = clarify his new proposal. =46rom my own reading in = draft-tschofenig-dime-overload-piggybacking in 3.2: >> ... the Diameter >> server (or a proxy, ....) may decide to communicate to the Diameter >> client to reject some or even all Diameter requests. The Diameter >> server does so by adding the Overload-Info AVP, which contains the >> Overload and the Period-Of-Validity AVP. >>=20 >> Then the overload AVP indicates to the client the amount of traffic = to decrease or to increase. So from my understanding, it is similar to = the implicit scope I have described as the piggybacked overload info is = related to the message transporting it, and in consequence does not = require to indicate an explicit scope.=20 >=20 > Do I understand correctly that you assume the traffic that should be = reduced is the set of future requests that have the same realm, = application-Id, and perhaps destination-host/origin-host that matches = that of the message containing the overload report? I don't recall = seeing text in the draft to indicate that, but might have missed = something. (If I did, please don't hesitate to educate me :-) ) >=20 >> I have other views on the content of the overload info where I am in = favour of an overload info indicating a % of traffic reduction to be = applied. I also consider the overlaod info is used by the throttling = entity which may be the client or an intermediate DA. Hannes only = mentions the client. >=20 > That would be similar to what is in draft-roach-dime-overload-ctrl, = when used with the included "loss" algorithm, right? (ignoring for the = moment issues of crossing non-supporting agents) >=20 >>=20 >> - about the comment "do you mean a default? (that is, one that = applies if no scope is explicitly included)?". The implicit scope I have = described is not a default scope, in the above meaning. It is implicit = because it applies to the traffic to which the message conveying the = overload info belongs. This scope is not exclusive of other scopes, but = for the many cases that it covers by itself, I do not foresee to use = it in conjunction with others. As mentioned, I would like to know use = cases, that this implicit scope will not cover and which other scopes or = extensions would be required. >=20 > The Roach draft currently has a "Connection" scope that takes it's = value from the connection on which the report arrived. It's an = explicitly included scope, but it's value is implicit. Is that the sort = of thing you have in mind, but for a different set of implicit values? = That is, we could have sort of a "this realm and application" scope? You = would explicitly include it, but the realm and application-ID values = would be implied by the message contents? >=20 > Thanks! >=20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Jul 29 01:36: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 6B32421F997D for ; Mon, 29 Jul 2013 01:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeQqSWxFyjBi for ; Mon, 29 Jul 2013 01:36:30 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3613221F8235 for ; Mon, 29 Jul 2013 01:36:30 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so4376215pbc.29 for ; Mon, 29 Jul 2013 01:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Qg28/m9I46Fjlkqd+SvumpAS0bJIZWjYeadPR2qEnUg=; b=TblWdCrD8SUQ0TaYUH1Kv5q6rs9md+Um369F1rf4YBUGpucGJYp2KhuF0GRTWWoLIq jLMe9V4kh0PYDpBUkSywKBOGonJQSFwMvkqjgtmkNP62wablO4upeu+q4vLFJM/ZwqLE abgXK4WG9WMgH5E9TcVG8PQfhdX7HYai+hbZINZoBXHEUehr8Vj51Vf1aMbHgRO4qdDD RY5Btu9K5QHvLoTxHo8aw01QbraEfTTUCbeKzUyg/lk0q5TpijkfP0nRsw5cYA/LDdRh fM3V9QySf2NDYEGGVbNWtnf+qdeiGV7vR403gG6M8PtA7jBgs9MQkbisDjku8YZrRq2f rvVw== X-Received: by 10.68.235.103 with SMTP id ul7mr66588604pbc.14.1375086989904; Mon, 29 Jul 2013 01:36:29 -0700 (PDT) Received: from ?IPv6:2001:df8::80:e97a:9420:feea:fa9d? ([2001:df8:0:80:e97a:9420:feea:fa9d]) by mx.google.com with ESMTPSA id pq1sm75622862pbb.26.2013.07.29.01.36.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:36:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 29 Jul 2013 11:36:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC9CD3D-0C48-4E7B-97F0-96D2AD3C4722@gmail.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> <26C84DFD55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1508) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope 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, 29 Jul 2013 08:36:34 -0000 I have been rather confused about this implicit scope so far. So let me = try to understand what you mean by it: You want to setup a "scope" without defining how the box comes up with = the set of information used to bind the commands to the scope? Rather, a = request that contains overload information sets up a scope if one does = not exist yet and by some magic the node picks up a set of AVPs (or = other information) that it uses as a "key" for scope matching.. After = that all commands that match to this undefined set of information = determine the scope? You really never want to explicitly describe the = information set that is used to match against the implicit scope? Am I = right? What is the lifetime of the implicit scope? - Jouni On Jul 29, 2013, at 11:06 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi Ben >=20 > The implicit scope I refer to (as well as Suzan) is effectively the = one related to the flow of requests that matches that of the message = containing the overload report. I would like this scope be part of the = solution, but the current draft, as you underlined, does not refer to = this scope. We will further discuss it during the IETF 87 meeting. >=20 > Best regards >=20 >=20 > JJacques=20 >=20 >=20 > -----Message d'origine----- > De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]=20 > Envoy=C3=A9 : lundi 29 juillet 2013 08:45 > =C3=80 : Ben Campbell; TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Cc : DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); = Bessis, Thierry (Thierry) > Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope >=20 > Hi Ben, Eric, >=20 > Coming back to the implicit or default Scope issue. >=20 > Whatever it is called as "implicit" or "default", my intention was = that for 3GPP applications, at least e.g. for S6a/S6d, there is no need = to have such an explicit Scope parameter to indicate the "scope" for = which the overload information applies. >=20 > My understanding of the two wording in the context here are very = similar, but if we have to differentiate them, "implicit" is more proper = to be used for the case we are addressing, which means there is no need = to have such a Scope defined, the overload information applies = implicitly to the scope implied by the information contained in the = message. >=20 > In the clause 5.2.3 for definition of Overload AVP in the "Diameter = Overload Architecture and Information Model" draft, the last sentence = says: >=20 > The increase and decrease of the sending rate refers to new requests > to the same realm and the same application ID as the message = carrying > the overload information. >=20 > which may imply such an implicit scope we are talking about. Hannes = may provide his interpretation. >=20 > Best Regards, > Susan >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Ben Campbell [mailto:ben@nostrum.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8826=E6=97=A5= 6:23 > =E6=94=B6=E4=BB=B6=E4=BA=BA: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > =E6=8A=84=E9=80=81: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel = (Nigel); Bessis, Thierry (Thierry) > =E4=B8=BB=E9=A2=98: Re: [Dime] Diameter Overload - Default "Implicit" = Scope >=20 > Hi JJaques, see comments inline: >=20 > On Jul 24, 2013, at 7:59 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >>=20 >> Dear all >>=20 >> I hereafter add some comments on two ones made in previous mails. >>=20 >> - there was the comment " I'm not sure I understand what the implicit = scope is in Hannes's draft".. I agree it would be good Hannes to = clarify his new proposal. =46rom my own reading in = draft-tschofenig-dime-overload-piggybacking in 3.2: >> ... the Diameter >> server (or a proxy, ....) may decide to communicate to the Diameter >> client to reject some or even all Diameter requests. The Diameter >> server does so by adding the Overload-Info AVP, which contains the >> Overload and the Period-Of-Validity AVP. >>=20 >> Then the overload AVP indicates to the client the amount of traffic = to decrease or to increase. So from my understanding, it is similar to = the implicit scope I have described as the piggybacked overload info is = related to the message transporting it, and in consequence does not = require to indicate an explicit scope.=20 >=20 > Do I understand correctly that you assume the traffic that should be = reduced is the set of future requests that have the same realm, = application-Id, and perhaps destination-host/origin-host that matches = that of the message containing the overload report? I don't recall = seeing text in the draft to indicate that, but might have missed = something. (If I did, please don't hesitate to educate me :-) ) >=20 >> I have other views on the content of the overload info where I am in = favour of an overload info indicating a % of traffic reduction to be = applied. I also consider the overlaod info is used by the throttling = entity which may be the client or an intermediate DA. Hannes only = mentions the client. >=20 > That would be similar to what is in draft-roach-dime-overload-ctrl, = when used with the included "loss" algorithm, right? (ignoring for the = moment issues of crossing non-supporting agents) >=20 >>=20 >> - about the comment "do you mean a default? (that is, one that = applies if no scope is explicitly included)?". The implicit scope I have = described is not a default scope, in the above meaning. It is implicit = because it applies to the traffic to which the message conveying the = overload info belongs. This scope is not exclusive of other scopes, but = for the many cases that it covers by itself, I do not foresee to use = it in conjunction with others. As mentioned, I would like to know use = cases, that this implicit scope will not cover and which other scopes or = extensions would be required. >=20 > The Roach draft currently has a "Connection" scope that takes it's = value from the connection on which the report arrived. It's an = explicitly included scope, but it's value is implicit. Is that the sort = of thing you have in mind, but for a different set of implicit values? = That is, we could have sort of a "this realm and application" scope? You = would explicitly include it, but the realm and application-ID values = would be implied by the message contents? >=20 > Thanks! >=20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From susan.shishufeng@huawei.com Mon Jul 29 02:25:42 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 18AB921E8089 for ; Mon, 29 Jul 2013 02:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-3.445, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWshhSS+HEpz for ; Mon, 29 Jul 2013 02:25:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C021F9FF7 for ; Mon, 29 Jul 2013 02:25:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVN23661; Mon, 29 Jul 2013 09:25:18 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 10:25:09 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 10:25:13 +0100 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.56]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 17:24:22 +0800 From: "Shishufeng (Susan)" To: Eric McMurry Thread-Topic: [Dime] Diameter Overload - Default "Implicit" Scope Thread-Index: AQHOibVnYJHVtWC8D0ORIz71Bpq75Zl7NILA//+bFYCAAJUUQA== Date: Mon, 29 Jul 2013 09:24:21 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F25717545DD@szxeml528-mbs.china.huawei.com> References: <73411B91-2933-40AD-AF1D-E68AF50980A6@computer.org> <75EB906B-81E6-48E8-AF10-B45EDE67A73A@nostrum.com> <37568683-E84A-4B82-AC96-5D21F01FA08A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F257175260E@szxeml528-mbs.china.huawei.com> <5D1A3A34-61C9-42A4-A00B-B21F57390AA6@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2571752825@szxeml528-mbs.china.huawei.com> <6933A704-656F-4B55-B835-D8BBC3BC4CE8@nostrum.com> <62723813-7AE4-40C6-BAF7-E9DB81444F52@nostrum.com> <26C84DF D55BC3040A45BF70926E55F25717544FD@szxeml528-mbs.china.huawei.com> <9939898B-D6BB-4C83-BDE1-7F081375E781@computer.org> In-Reply-To: <9939898B-D6BB-4C83-BDE1-7F081375E781@computer.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "dime@ietf.org" Subject: [Dime] =?gb2312?b?tPC4tDogIERpYW1ldGVyIE92ZXJsb2FkIC0gRGVmYXVs?= =?gb2312?b?dCAiSW1wbGljaXQiIFNjb3Bl?= 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, 29 Jul 2013 09:25:43 -0000 SGkgRXJpYywNCg0KUzYgaXMganVzdCBhbiBleGFtcGxlLCBob3dldmVyLCBpdCBzZWVtcyB0aGF0 IHRoZSBpbXBsaWNpdCBzY29wZSB3ZSBwcm9wb3NlZCBjYW4gYmUgYXBwbGllZCB0byBvdGhlciAz R1BQIERpYW1ldGVyIGFwcGxpY2F0aW9ucyBhcyB3ZWxsLiBPciBJIHdvdWxkIGFzayBpZiB0aGVy ZSBhcmUgb3RoZXIgY2FzZXMgd2hpY2ggY2Fubm90IGJlIGNvdmVyZWQgYnkgdGhlIGltcGxpY2l0 IHNjb3BlPyBTaW1pbGFyIHF1ZXN0aW9uIGFzIHJhaXNlZCBieSBKSiBpbiBwcmV2aW91cyBtYWls Lg0KDQpCZXN0IFJlZ2FyZHMsDQpTdXNhbg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog RXJpYyBNY011cnJ5IFttYWlsdG86ZW1jbXVycnlAY29tcHV0ZXIub3JnXSANCreiy83KsbzkOiAy MDEzxOo31MIyOcjVIDE2OjIxDQrK1bz+yMs6IFNoaXNodWZlbmcgKFN1c2FuKQ0Ks63LzTogQmVu IENhbXBiZWxsOyBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUyk7IERSQUdFLCBL ZWl0aCAoS2VpdGgpOyBkaW1lQGlldGYub3JnOyBCZXNzaXMsIFRoaWVycnkgKFRoaWVycnkpOyBC RVJSWSwgTmlnZWwgKE5pZ2VsKQ0K1vfM4jogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9hZCAt IERlZmF1bHQgIkltcGxpY2l0IiBTY29wZQ0KDQpIaSBTdXNhbiwNCg0KU28sIEkgdGhpbmsgeW91 IGFyZSBhc2tpbmcgZm9yIGEgZGVmYXVsdCBzY29wZSAoYWxzbyBhIGNvbWJpbmVkIHNjb3BlKSB0 aGF0IHVzZXMgaW1wbGljaXQgaW5mb3JtYXRpb24uICBUaGF0IGlzLCB5b3Ugd2FudCBhIHNjb3Bl IHRoYXQgYXBwbGllcyB3aGVuIHRoZXJlIGFyZSBubyBzY29wZXMgY2FsbGVkIG91dCAoZGVmYXVs dCkgYW5kIHlvdSB3YW50IGl0IHRvIHVzZSBpbmZvcm1hdGlvbiBkZXJpdmVkIGZyb20gb3RoZXIg cGFydHMgb2YgdGhlIG1lc3NhZ2UgaXQncyBwaWdneWJhY2tlZCBvbiAoaW1wbGljaXQpLg0KDQpJ IGhhdmUgbm8gaXNzdWUgd2l0aCB0aGUgY29uY2VwdHMgaGVyZSBpbiBnZW5lcmFsLiAgSSB0aGlu ayBwaWNraW5nIHNvbWV0aGluZyBzcGVjaWZpYyB0byBTNiBtYXkgbm90IGJlIHRoZSBiZXN0IGFw cHJvYWNoIHRob3VnaC4gIEkgc3RhcnRlZCB0cnlpbmcgdG8gZW51bWVyYXRlIHRoZSBzY2VuYXJp b3MgYW5kIHRoZSB1c2VmdWwgc2NvcGVzIHRvIGdvIHdpdGggdGhlbSB0byBzZWUgaWYgdGhlcmUg d2FzIGEgZGVmYXVsdCB0aGF0IHdvdWxkIGJlIHVzZWZ1bCBpbiBtYW55IGNhc2VzLCBidXQgdGhl IG51bWJlciBvZiB3YXlzIHRoYXQgc2NvcGVzIHdvdWxkIGJlIHVzZWQgZm9yIHZhcmlvdXMgc2Nl bmFyaW9zIChub3QganVzdCB0b3BvbG9naWVzLCBkaWZmZXJlbnQgc2NvcGVzIG1ha2Ugc2Vuc2Ug Zm9yIGRpZmZlcmVudCB0aGluZ3Mgb24gdGhlIHNhbWUgdG9wb2xvZ3kgYW5kIGNvbm5lY3Rpb25z KSB0aGF0IHRoZXJlIHdhcyBubyBvYnZpb3VzIGFuc3dlci4NCg0KQmVuIGhhcyBwcm9wb3NlZCB0 aGUgYWJpbGl0eSB0byBzcGVjaWZ5IGFuIGltcGxpY2l0IHZhbHVlIG9uIHNjb3BlcyB3aGVyZSB0 aGF0IG1ha2VzIHNlbnNlIChJIGZvcmdldCBoaXMgbGlzdCwgYnV0IEkgdGhpbmsgdGhlcmUgYXJl IHNldmVyYWwgc2NvcGVzIHRoaXMgY291bGQgYmUgZG9uZSBmb3IpLiAgVGhpcyBtYWtlcyBzZW5z ZSBhbmQgSSB0aGluayB3b3VsZCBjYXRjaCB3aGF0IHlvdSBhcmUgYWZ0ZXIgKGFzIHdlbGwgYXMg SSB1bmRlcnN0YW5kIGl0KSBmb3IgdGhhdCBwYXJ0LiAgRm9yIHRoZSBkZWZhdWx0IHBhcnQsIEkg dGhpbmsgbW9yZSBhbmFseXNpcyBpcyBuZWVkZWQuICBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCB0 aGVyZSBpcyBhbnl0aGluZyByZWFzb25hYmxlIGhlcmUgKHRoZXJlIGFyZSB0b28gbWFueSBjYXNl cyBhbmQgZGVmYXVsdHMgd291bGQgYmUgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgdG9wb2xvZ2ll cy9zY2VuYXJpb3MpIG9yIHRoYXQgaGF2aW5nIHRvIHB1dCBhIHNjb3BlIG9uIGNvbnRyb2wgaW5m b3JtYXRpb24gaXMgcmVhbGx5IGFuIGlzc3VlICh0aGlzIHNvdW5kcyBsaWtlIGEgZmV3IGxpbmVz IG9mIGNvZGUgdG8gbWUpLg0KDQpUaGFua3MsDQoNCkVyaWMNCg0KDQpPbiBKdWwgMjksIDIwMTMs IGF0IDg6NDUgLCBTaGlzaHVmZW5nIChTdXNhbikgPHN1c2FuLnNoaXNodWZlbmdASFVBV0VJLkNP TT4gd3JvdGU6DQoNCj4gSGkgQmVuLCBFcmljLA0KPiANCj4gQ29taW5nIGJhY2sgdG8gdGhlIGlt cGxpY2l0IG9yIGRlZmF1bHQgU2NvcGUgaXNzdWUuDQo+IA0KPiBXaGF0ZXZlciBpdCBpcyBjYWxs ZWQgYXMgImltcGxpY2l0IiBvciAiZGVmYXVsdCIsIG15IGludGVudGlvbiB3YXMgdGhhdCBmb3Ig M0dQUCBhcHBsaWNhdGlvbnMsIGF0IGxlYXN0IGUuZy4gZm9yIFM2YS9TNmQsIHRoZXJlIGlzIG5v IG5lZWQgdG8gaGF2ZSBzdWNoIGFuIGV4cGxpY2l0IFNjb3BlIHBhcmFtZXRlciB0byBpbmRpY2F0 ZSB0aGUgInNjb3BlIiBmb3Igd2hpY2ggdGhlIG92ZXJsb2FkIGluZm9ybWF0aW9uIGFwcGxpZXMu DQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0d28gd29yZGluZyBpbiB0aGUgY29udGV4 dCBoZXJlIGFyZSB2ZXJ5IHNpbWlsYXIsIGJ1dCBpZiB3ZSBoYXZlIHRvIGRpZmZlcmVudGlhdGUg dGhlbSwgImltcGxpY2l0IiBpcyBtb3JlIHByb3BlciB0byBiZSB1c2VkIGZvciB0aGUgY2FzZSB3 ZSBhcmUgYWRkcmVzc2luZywgd2hpY2ggbWVhbnMgdGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIHN1 Y2ggYSBTY29wZSBkZWZpbmVkLCB0aGUgb3ZlcmxvYWQgaW5mb3JtYXRpb24gYXBwbGllcyBpbXBs aWNpdGx5IHRvIHRoZSBzY29wZSBpbXBsaWVkIGJ5IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhlIG1lc3NhZ2UuDQo+IA0KPiBJbiB0aGUgY2xhdXNlIDUuMi4zIGZvciBkZWZpbml0aW9u IG9mIE92ZXJsb2FkIEFWUCBpbiB0aGUgIkRpYW1ldGVyIE92ZXJsb2FkIEFyY2hpdGVjdHVyZSBh bmQgSW5mb3JtYXRpb24gTW9kZWwiIGRyYWZ0LCB0aGUgbGFzdCBzZW50ZW5jZSBzYXlzOg0KPiAN Cj4gICBUaGUgaW5jcmVhc2UgYW5kIGRlY3JlYXNlIG9mIHRoZSBzZW5kaW5nIHJhdGUgcmVmZXJz IHRvIG5ldyByZXF1ZXN0cw0KPiAgIHRvIHRoZSBzYW1lIHJlYWxtIGFuZCB0aGUgc2FtZSBhcHBs aWNhdGlvbiBJRCBhcyB0aGUgbWVzc2FnZSBjYXJyeWluZw0KPiAgIHRoZSBvdmVybG9hZCBpbmZv cm1hdGlvbi4NCj4gDQo+IHdoaWNoIG1heSBpbXBseSBzdWNoIGFuIGltcGxpY2l0IHNjb3BlIHdl IGFyZSB0YWxraW5nIGFib3V0LiBIYW5uZXMgbWF5IHByb3ZpZGUgaGlzIGludGVycHJldGF0aW9u Lg0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiBTdXNhbg0KPiANCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXSANCj4gt6LL zcqxvOQ6IDIwMTPE6jfUwjI2yNUgNjoyMw0KPiDK1bz+yMs6IFRST1RUSU4sIEpFQU4tSkFDUVVF UyAoSkVBTi1KQUNRVUVTKQ0KPiCzrcvNOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgZGltZUBpZXRm Lm9yZzsgQkVSUlksIE5pZ2VsIChOaWdlbCk7IEJlc3NpcywgVGhpZXJyeSAoVGhpZXJyeSkNCj4g 1vfM4jogUmU6IFtEaW1lXSBEaWFtZXRlciBPdmVybG9hZCAtIERlZmF1bHQgIkltcGxpY2l0IiBT Y29wZQ0KPiANCj4gSGkgSkphcXVlcywgc2VlIGNvbW1lbnRzIGlubGluZToNCj4gDQo+IE9uIEp1 bCAyNCwgMjAxMywgYXQgNzo1OSBBTSwgIlRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNR VUVTKSIgPGplYW4tamFjcXVlcy50cm90dGluQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+ IA0KPj4gDQo+PiBEZWFyIGFsbA0KPj4gDQo+PiBJIGhlcmVhZnRlciBhZGQgc29tZSBjb21tZW50 cyBvbiB0d28gb25lcyBtYWRlIGluIHByZXZpb3VzIG1haWxzLg0KPj4gDQo+PiAtIHRoZXJlIHdh cyB0aGUgY29tbWVudCAiIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW1wbGlj aXQgc2NvcGUgaXMgaW4gSGFubmVzJ3MgZHJhZnQiLi4gIEkgYWdyZWUgaXQgd291bGQgYmUgZ29v ZCBIYW5uZXMgdG8gY2xhcmlmeSBoaXMgbmV3IHByb3Bvc2FsLiBGcm9tIG15IG93biByZWFkaW5n IGluIGRyYWZ0LXRzY2hvZmVuaWctZGltZS1vdmVybG9hZC1waWdneWJhY2tpbmcgaW4gIDMuMjoN Cj4+ICAuLi4gdGhlIERpYW1ldGVyDQo+PiAgc2VydmVyIChvciBhIHByb3h5LCAuLi4uKSBtYXkg ZGVjaWRlIHRvIGNvbW11bmljYXRlIHRvIHRoZSBEaWFtZXRlcg0KPj4gIGNsaWVudCB0byByZWpl Y3Qgc29tZSBvciBldmVuIGFsbCBEaWFtZXRlciByZXF1ZXN0cy4gVGhlIERpYW1ldGVyDQo+PiAg c2VydmVyIGRvZXMgc28gYnkgYWRkaW5nIHRoZSBPdmVybG9hZC1JbmZvIEFWUCwgd2hpY2ggY29u dGFpbnMgdGhlDQo+PiAgT3ZlcmxvYWQgYW5kIHRoZSBQZXJpb2QtT2YtVmFsaWRpdHkgQVZQLg0K Pj4gDQo+PiBUaGVuIHRoZSBvdmVybG9hZCBBVlAgaW5kaWNhdGVzIHRvIHRoZSBjbGllbnQgdGhl IGFtb3VudCBvZiB0cmFmZmljIHRvIGRlY3JlYXNlIG9yIHRvIGluY3JlYXNlLiBTbyBmcm9tIG15 IHVuZGVyc3RhbmRpbmcsIGl0IGlzIHNpbWlsYXIgdG8gdGhlIGltcGxpY2l0IHNjb3BlIEkgaGF2 ZSBkZXNjcmliZWQgYXMgdGhlIHBpZ2d5YmFja2VkIG92ZXJsb2FkIGluZm8gaXMgcmVsYXRlZCB0 byB0aGUgbWVzc2FnZSB0cmFuc3BvcnRpbmcgaXQsIGFuZCBpbiBjb25zZXF1ZW5jZSBkb2VzIG5v dCByZXF1aXJlIHRvIGluZGljYXRlIGFuIGV4cGxpY2l0IHNjb3BlLiANCj4gDQo+IERvIEkgdW5k ZXJzdGFuZCBjb3JyZWN0bHkgdGhhdCB5b3UgYXNzdW1lIHRoZSB0cmFmZmljIHRoYXQgc2hvdWxk IGJlIHJlZHVjZWQgaXMgdGhlIHNldCBvZiBmdXR1cmUgcmVxdWVzdHMgdGhhdCBoYXZlIHRoZSBz YW1lIHJlYWxtLCBhcHBsaWNhdGlvbi1JZCwgYW5kIHBlcmhhcHMgZGVzdGluYXRpb24taG9zdC9v cmlnaW4taG9zdCB0aGF0IG1hdGNoZXMgdGhhdCBvZiB0aGUgbWVzc2FnZSBjb250YWluaW5nIHRo ZSBvdmVybG9hZCByZXBvcnQ/IEkgZG9uJ3QgcmVjYWxsIHNlZWluZyB0ZXh0IGluIHRoZSBkcmFm dCB0byBpbmRpY2F0ZSB0aGF0LCBidXQgbWlnaHQgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLiAoSWYg SSBkaWQsIHBsZWFzZSBkb24ndCBoZXNpdGF0ZSB0byBlZHVjYXRlIG1lIDotKSAgKQ0KPiANCj4+ IEkgaGF2ZSBvdGhlciB2aWV3cyBvbiB0aGUgY29udGVudCBvZiB0aGUgb3ZlcmxvYWQgaW5mbyB3 aGVyZSAgSSBhbSBpbiBmYXZvdXIgb2YgYW4gb3ZlcmxvYWQgaW5mbyBpbmRpY2F0aW5nIGEgJSBv ZiB0cmFmZmljIHJlZHVjdGlvbiB0byBiZSBhcHBsaWVkLiBJIGFsc28gY29uc2lkZXIgdGhlIG92 ZXJsYW9kIGluZm8gaXMgdXNlZCBieSB0aGUgdGhyb3R0bGluZyBlbnRpdHkgd2hpY2ggbWF5IGJl IHRoZSBjbGllbnQgb3IgYW4gaW50ZXJtZWRpYXRlIERBLiBIYW5uZXMgb25seSBtZW50aW9ucyB0 aGUgY2xpZW50Lg0KPiANCj4gVGhhdCB3b3VsZCBiZSBzaW1pbGFyIHRvIHdoYXQgaXMgaW4gZHJh ZnQtcm9hY2gtZGltZS1vdmVybG9hZC1jdHJsLCB3aGVuIHVzZWQgd2l0aCB0aGUgaW5jbHVkZWQg Imxvc3MiIGFsZ29yaXRobSwgcmlnaHQ/IChpZ25vcmluZyBmb3IgdGhlIG1vbWVudCBpc3N1ZXMg b2YgY3Jvc3Npbmcgbm9uLXN1cHBvcnRpbmcgYWdlbnRzKQ0KPiANCj4+IA0KPj4gLSBhYm91dCB0 aGUgY29tbWVudCAiZG8geW91IG1lYW4gYSBkZWZhdWx0PyAodGhhdCBpcywgb25lIHRoYXQgYXBw bGllcyBpZiBubyBzY29wZSBpcyBleHBsaWNpdGx5IGluY2x1ZGVkKT8iLiBUaGUgaW1wbGljaXQg c2NvcGUgSSBoYXZlIGRlc2NyaWJlZCBpcyBub3QgYSBkZWZhdWx0IHNjb3BlLCBpbiB0aGUgYWJv dmUgbWVhbmluZy4gSXQgaXMgaW1wbGljaXQgYmVjYXVzZSBpdCBhcHBsaWVzIHRvIHRoZSB0cmFm ZmljIHRvIHdoaWNoIHRoZSBtZXNzYWdlIGNvbnZleWluZyB0aGUgb3ZlcmxvYWQgaW5mbyBiZWxv bmdzLiBUaGlzIHNjb3BlIGlzIG5vdCBleGNsdXNpdmUgb2Ygb3RoZXIgc2NvcGVzLCBidXQgZm9y IHRoZSBtYW55IGNhc2VzIHRoYXQgaXQgY292ZXJzIGJ5IGl0c2VsZiwgIEkgZG8gbm90IGZvcmVz ZWUgIHRvIHVzZSBpdCBpbiBjb25qdW5jdGlvbiB3aXRoIG90aGVycy4gQXMgbWVudGlvbmVkLCBJ IHdvdWxkIGxpa2UgdG8ga25vdyB1c2UgY2FzZXMsIHRoYXQgdGhpcyBpbXBsaWNpdCBzY29wZSB3 aWxsIG5vdCBjb3ZlciBhbmQgd2hpY2ggb3RoZXIgc2NvcGVzIG9yIGV4dGVuc2lvbnMgd291bGQg YmUgcmVxdWlyZWQuDQo+IA0KPiBUaGUgUm9hY2ggZHJhZnQgY3VycmVudGx5IGhhcyBhICJDb25u ZWN0aW9uIiBzY29wZSB0aGF0IHRha2VzIGl0J3MgdmFsdWUgZnJvbSB0aGUgY29ubmVjdGlvbiBv biB3aGljaCB0aGUgcmVwb3J0IGFycml2ZWQuIEl0J3MgYW4gZXhwbGljaXRseSBpbmNsdWRlZCBz Y29wZSwgYnV0IGl0J3MgdmFsdWUgaXMgaW1wbGljaXQuIElzIHRoYXQgdGhlIHNvcnQgb2YgdGhp bmcgeW91IGhhdmUgaW4gbWluZCwgYnV0IGZvciBhIGRpZmZlcmVudCBzZXQgb2YgaW1wbGljaXQg dmFsdWVzPyBUaGF0IGlzLCB3ZSBjb3VsZCBoYXZlIHNvcnQgb2YgYSAidGhpcyByZWFsbSBhbmQg YXBwbGljYXRpb24iIHNjb3BlPyBZb3Ugd291bGQgZXhwbGljaXRseSBpbmNsdWRlIGl0LCBidXQg dGhlIHJlYWxtIGFuZCBhcHBsaWNhdGlvbi1JRCB2YWx1ZXMgd291bGQgYmUgaW1wbGllZCBieSB0 aGUgbWVzc2FnZSBjb250ZW50cz8NCj4gDQo+IFRoYW5rcyENCj4gDQo+IEJlbi4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5n IGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RpbWUNCg0K From internet-drafts@ietf.org Mon Jul 29 04:15:49 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 403C821F99AE; Mon, 29 Jul 2013 04:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCogeB318faQ; Mon, 29 Jul 2013 04:15:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C421F9D52; Mon, 29 Jul 2013 04:15:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729111545.12487.46944.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 04:15:45 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:15:49 -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 : Realm-Based Redirection In Diameter Author(s) : Tina Tsou Ruibing Hao Tom Taylor Filename : draft-ietf-dime-realm-based-redirect-10.txt Pages : 8 Date : 2013-07-29 Abstract: The Diameter protocol allows a Diameter redirect agent to return to the message sender one or more individual hosts as destinations of the redirected message. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-realm-based-redirect-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Mon Jul 29 05:07:23 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 60BAB21F9E0B for ; Mon, 29 Jul 2013 05:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf61rKhOtVQO for ; Mon, 29 Jul 2013 05:07:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BD29F21F9D56 for ; Mon, 29 Jul 2013 05:06:40 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lu3J4-1U2dSL15zK-011P8I for ; Mon, 29 Jul 2013 14:06:39 +0200 From: Hannes Tschofenig Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="Apple-Mail-20--492077124" Date: Mon, 29 Jul 2013 14:06:37 +0200 References: <1373E8CE237FCC43BCA36C6558612D2AA1FC14@USCHMBX001.nsn-intra.net> To: dime@ietf.org Message-Id: <7D12DC96-E091-4CB1-8054-5C31C3E99C0E@gmx.net> Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:B0SXkGDynmFNuTtKKyK/KsRHG+1H0mx9VaaBxmPA8mDz9OTqOtH jLj3oY0t97nwsd2lkH2mF8ob4Ir9ogek0i60PckOv2DvOXAb9ZW8eCqgdwP3y+7GAdVePDJ D90H+sFvhtU/dWkk5ASjqU9OGjp4wMPq3ccPs82+8AcQr54zD+ipeXbUTX1Gn3cTAPDYHFt Jr3vJ6WiwinbXjwTjHLfg== Cc: Sebastien Decugis Subject: [Dime] Fwd: Feedback on overload set of docs 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, 29 Jul 2013 12:07:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-20--492077124 Content-Type: multipart/alternative; boundary=Apple-Mail-19--492077171 --Apple-Mail-19--492077171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 I asked Sebastien to provide feedback about the overload documents I = recently submitted to the working group to determine how difficult it = would be to implement them in freeDiameter. Sebastien is the person = behind freeDiameter (as most of you know).=20 Ciao Hannes > From: ext Sebastien > Sent: 7/21/2013 17:35 > To: Tschofenig, Hannes (NSN - FI/Espoo) > Subject: Feedback on overload set of docs >=20 > Hi Hannes, >=20 > I have read the set of documents for overload=20 > (draft-ietf-dime-overload-reqs-07,=20 > draft-tschofenig-dime-overload-arch-00, draft-tschofenig-dime-dlba-00,=20= > draft-tschofenig-dime-overload-piggybacking-00) >=20 > Concerning the load-balancing application, it should be quite=20 > straight-forward to implement this. There are already some metrics=20 > available in freeDiameter to get a hint of the current load, and there=20= > is also all the support in freeDiameter to implement any = load-balancing=20 > algorithm you like. I even have an example of a load-balancing=20 > application [1] that is based on the load of the different backend=20 > servers (but measured by the number of pending requests for those=20 > servers, not by information received remotely). Note that for the part=20= > about PPID, you'd have to change some code in the lower layer of=20 > freeDiameter, as such control is not provided through the normal API = of=20 > the framework (at the moment at least). >=20 > The requirements document distinguish between the "global" load of a=20= > Diameter node (let's call this Base Protocol Load) and a specific=20 > application load. All the metrics I have in freeDiameter concern only=20= > the base protocol load. If a specific application wanted to use some=20= > mechanism to report its own load, it would have to implement this = logic=20 > itself. One the other hand, I don't see how your DLBA fits with this=20= > requirement either... >=20 > ...I guess your plan is to address this with the piggybacked AVPs in = the=20 > application's messages. Note that for this piggy-backed mechanism, I = do=20 > not really see the value of the "Supported-Feature" AVP: it is not=20 > important for the client to signal the support of the mechanism to the=20= > server, as it can ignore the piggybacked AVPs anyway if it does not=20 > understand them. >=20 > For implementing the piggybacking, it is easy to add an AVP to a=20 > message, but it is more difficult to know when / where to do it. Today=20= > all the applications provided in freeDiameter consume the requests=20 > synchronously, so their load state directly matchs the "base protocol=20= > load" (i.e. as soon as one application becomes overloaded, the = complete=20 > node is overloaded). If you want to have an application-specific load,=20= > you need to "consume" quickly the request received by your application=20= > callback and just store it for asynchronous processing. Then your=20 > application load state will be the status of this asynchronous=20 > processing queue. This requires some additional logic, and I do not = have=20 > any example available publicly at the moment -- although I know some=20= > users have implemented such logic successfully already. >=20 > I hope this answers your question :-) >=20 > I have some additional comments on=20 > http://tools.ietf.org/html/draft-tschofenig-dime-overload-arch-00 = (just=20 > FYI, feel free to ignore those) >=20 > 3. Architectural Principles: > I don't understand the issue with rejecting Requests ("requires=20 > signaling to the Diameter clients") =3D> this is exactly the same as = when=20 > the authentication fails for example. Today when I try to use my phone=20= > during new year's eve, the call just fails, I don't receive a status=20= > that the network is too busy (and I would not care). The information=20= > that it is failing because of overload is only useful to the Diameter=20= > nodes that could take a corrective action, such as sending to another=20= > backend. As you know Diameter base protocol already has a status=20 > DIAMETER_TOO_BUSY. An agent that receives this status can choose to=20 > resend the request to another backend or forward the error to the=20 > client. A Diameter client that receives this error can treat it is the=20= > same way as a failure to authenticate, since it is an error, and just=20= > deny the access to the user -- and an error message can be included as=20= > well in the Diameter answer, that can be forwarded to the connecting = device. >=20 > 5.2.3. Overload AVP. > I am not sure "increasing overload" and "decreasing overload" makes = any=20 > sense. You can quantify the load, e.g. from 0% to 100%, then you are = in=20 > overload state where the Diameter server is not able to handle any new=20= > request until it has processed the previous ones (because there is a=20= > resource shortage). That's consistent with your Load AVP from 0 to 10.=20= > Or, we have a different definition for Overload state, that I am not=20= > familiar with. >=20 > In freeDiameter, the situation is as follow: > - a given server has a given processing capability, resulting in a = given=20 > maximum throughput (the limit). > - if the messages are incoming with a rate lower than this limit,=20 > everything is well. > - when there is a burst of messages that goes over the limit rate, the=20= > messages start to be queued and the processing is slightly delayed. = The=20 > more the queue length increases, the more the messages are delayed. > - there is a limit to the maximum length of the queue in freeDiameter,=20= > once this limit is reached the framework does not read from the = network=20 > socket until the next message is processed -- the lower layer = congestion=20 > control will then start to kick in. > - when I measure the "load" of the framework, it is the length of the=20= > queue. I know I am overloaded if the length is equal to the maximum = for=20 > the queue. >=20 >=20 > I am also not sure that the Overload information can be useful for the=20= > Diameter client (when you write: "The increase and decrease of the=20 > sending rate refers to new requests to the same realm and the same=20 > application ID as the message carrying the overload information."). In=20= > some real-life setups I have seen, the requests are dispatched by an=20= > agent to different backends in the same realm depending on for e.g. = the=20 > User-Name (some users having been migrated to a new server). So, even = if=20 > one backend is overloaded, it does not mean that the complete realm=20 > cannot answer anymore. Do you expect an agent to intercept this AVP in=20= > such situation? >=20 > [1] rt_load_balance extension. The complete code takes less than 100=20= > lines with comments:=20 > = http://www.freediameter.net/hg/freeDiameter-proposed/file/e72c9dad62ac/ext= ensions/rt_load_balance/rt_load_balance.c >=20 > Cheers, > Sebastien. >=20 --Apple-Mail-19--492077171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sebastien to provide feedback about the overload = documents I recently submitted to the working group to determine how = difficult it would be to implement them in freeDiameter. Sebastien is = the person behind freeDiameter (as most of you = know). 
From: ext = Sebastien
Sent: 7/21/2013 = 17:35
To: Tschofenig, = Hannes (NSN - FI/Espoo)
Subject: Feedback on = overload set of docs

Hi Hannes,

I = have read the set of documents for overload 
(draft-ietf-dime-overload= -reqs-07, 
draft-tschofenig-dime-ove= rload-arch-00, draft-tschofenig-dime-dlba-00, 
draft-tschofenig-dime-ove= rload-piggybacking-00)

Concerning the load-balancing application, = it should be quite 
straight-forward to = implement this. There are already some metrics 
available in = freeDiameter to get a hint of the current load, and there 
is also all the support = in freeDiameter to implement any load-balancing 
algorithm you like. I = even have an example of a load-balancing 
application [1] that is = based on the load of the different backend 
servers (but measured = by the number of pending requests for those 
servers, not by = information received remotely). Note that for the part 
about PPID, you'd have = to change some code in the lower layer of 
freeDiameter, as such = control is not provided through the normal API of 
the framework (at the = moment at least).

The requirements document distinguish between = the "global" load of a 
Diameter node (let's = call this Base Protocol Load) and a specific 
application load. All = the metrics I have in freeDiameter concern only 
the base protocol load. = If a specific application wanted to use some 
mechanism to report its = own load, it would have to implement this logic 
itself. One the other = hand, I don't see how your DLBA fits with this 
requirement = either...

...I guess your plan is to address this with the = piggybacked AVPs in the 
application's messages. = Note that for this piggy-backed mechanism, I do 
not really see the = value of the "Supported-Feature" AVP: it is not 
important for the = client to signal the support of the mechanism to the 
server, as it can = ignore the piggybacked AVPs anyway if it does not 
understand = them.

For implementing the piggybacking, it is easy to add an AVP = to a 
message, but = it is more difficult to know when / where to do it. Today 
all the applications = provided in freeDiameter consume the requests 
synchronously, so their = load state directly matchs the "base protocol 
load" (i.e. as soon as = one application becomes overloaded, the complete 
node is overloaded). If = you want to have an application-specific load, 
you need to "consume" = quickly the request received by your application 
callback and just store = it for asynchronous processing. Then your 
application load state = will be the status of this asynchronous 
processing queue. This = requires some additional logic, and I do not have 
any example available = publicly at the moment -- although I know some 
users have implemented = such logic successfully already.

I hope this answers your = question :-)

I have some additional comments on 
http://tools.ietf.org/html/draft-tschofenig-dime-overload-arch-00 (just 
FYI, feel free to = ignore those)

3. Architectural Principles:
I don't understand = the issue with rejecting Requests ("requires 
signaling to the = Diameter clients") =3D> this is exactly the same as when 
the authentication = fails for example. Today when I try to use my phone 
during new year's eve, = the call just fails, I don't receive a status 
that the network is too = busy (and I would not care). The information 
that it is failing = because of overload is only useful to the Diameter 
nodes that could take a = corrective action, such as sending to another 
backend. As you know = Diameter base protocol already has a status 
DIAMETER_TOO_BUSY. An = agent that receives this status can choose to 
resend the request to = another backend or forward the error to the 
client. A Diameter = client that receives this error can treat it is the 
same way as a failure = to authenticate, since it is an error, and just 
deny the access to the = user -- and an error message can be included as 
well in the Diameter = answer, that can be forwarded to the connecting device.

5.2.3. = Overload AVP.
I am not sure "increasing overload" and "decreasing = overload" makes any 
sense. You can quantify = the load, e.g. from 0% to 100%, then you are in 
overload state where = the Diameter server is not able to handle any new 
request until it has = processed the previous ones (because there is a 
resource shortage). = That's consistent with your Load AVP from 0 to 10. 
Or, we have a different = definition for Overload state, that I am not 
familiar = with.

In freeDiameter, the situation is as follow:
- a given = server has a given processing capability, resulting in a given 
maximum throughput (the = limit).
- if the messages are incoming with a rate lower than this = limit, 
everything = is well.
- when there is a burst of messages that goes over the limit = rate, the 
messages = start to be queued and the processing is slightly delayed. The 
more the queue length = increases, the more the messages are delayed.
- there is a limit to = the maximum length of the queue in freeDiameter, 
once this limit is = reached the framework does not read from the network 
socket until the next = message is processed -- the lower layer congestion 
control will then start = to kick in.
- when I measure the "load" of the framework, it is the = length of the 
queue.= I know I am overloaded if the length is equal to the maximum for 
the queue.


I = am also not sure that the Overload information can be useful for = the 
Diameter = client (when you write: "The increase and decrease of the 
sending rate refers to = new requests to the same realm and the same 
application ID as the = message carrying the overload information."). In 
some real-life setups I = have seen, the requests are dispatched by an 
agent to different = backends in the same realm depending on for e.g. the 
User-Name (some users = having been migrated to a new server). So, even if 
one backend is = overloaded, it does not mean that the complete realm 
cannot answer anymore. = Do you expect an agent to intercept this AVP in 
such = situation?

[1] rt_load_balance extension. The complete code takes = less than 100 
lines = with comments: 
http://www.freediameter= .net/hg/freeDiameter-proposed/file/e72c9dad62ac/extensions/rt_load_balance= /rt_load_balance.c

Cheers,
Sebastien.


= --Apple-Mail-19--492077171-- --Apple-Mail-20--492077124 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR9lrOAAoJEGhJURNOOiAth5EIAI1reEv3Uj4LXGfXatP3qqO6 Wj1mvHK8IEsyHXWqviOW6Y4rEKCXW6g3kU+9OVMZ57FjA4VpO8Sm4daU3j9ljdo9 Tvd/b5PLNA3U5L6+uu0aQUfacmsrT3GiIx2ZMwCI1u6Lo9WXuqQAXEvWa8A+6UHy 1NSs5hS6Zh+XSW1OfmcT31M3B8dukPxcSCxALeLWb4az15YVL6H1vC3c/dnJH52f XDGgRTItDdFJt1NmxihddvLSHbCIRl1b+kxG86LEONYvxlOG3feCnOXAuQDc7VNv XxY9rU5l6lBB/XXruIE4SqDpGkztoKXICUlbmyOUx5Umw+TDW6etwob2LmBYtL4= =CJl9 -----END PGP SIGNATURE----- --Apple-Mail-20--492077124-- From jouni.nospam@gmail.com Mon Jul 29 05:38:01 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 060CC21F9E15 for ; Mon, 29 Jul 2013 05:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Iony+2hCJBG for ; Mon, 29 Jul 2013 05:37:59 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 71C5C21F9CC7 for ; Mon, 29 Jul 2013 05:37:05 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so5825891pab.17 for ; Mon, 29 Jul 2013 05:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=f8cNjIoUi2KxGmdJXVsiNwg+bdNc+xuKO04yhtVZnro=; b=GWfDaukkXhKSrAYVHeHwtK/Bv5OQbzKVpJUEmnIclqhMYI3TWJuMtApGI1+eBJWZse A885mQRPCvZfUT6ElmqxTU+dr8e+XrelR1FqYfCeaVQmcAFjmY8MCTZuY4JsYK0f/2R4 ZWn4gCsRR2C/IBYJxSFqH4Uw5s433BuslMqP8YgHDQs5lCweWd2eu5lpODcsNmnWW0+Y DzRnSmo2BiniyPq7VoUSYMuYODjS+JQ555NqqYuIEXZ+oFx+r/NlrJq8bHC37DBz1Dkg yJvoaYIs0nmYV/VWQDCWaOBcH3XyyeeqHfmnxVTei1YJPMcrDKoqKXzrx6u7IB9Wif1H 4noA== X-Received: by 10.67.22.69 with SMTP id hq5mr46666667pad.174.1375101425158; Mon, 29 Jul 2013 05:37:05 -0700 (PDT) Received: from ?IPv6:2001:df8::80:58a8:b8da:677b:2aac? ([2001:df8:0:80:58a8:b8da:677b:2aac]) by mx.google.com with ESMTPSA id t9sm18890414pba.46.2013.07.29.05.36.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 05:37:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> Date: Mon, 29 Jul 2013 15:36:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1C032E7C-18B4-450C-BE27-8E59D1146F98@gmail.com> References: <4ECF699D-C0AE-436B-BF2F-5776EE166255@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 29 Jul 2013 12:38:01 -0000 Hannes, On Jul 18, 2013, at 12:38 PM, Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi Jouni,=20 >=20 > a very direct question.=20 >=20 > There are two differences:=20 >=20 > 1) The load balancing and the overload communication is separated into = two independent documents. I believe they are different in their nature. = While this may be seen only as a document handling issue many companies = already have solutions for load balancing in use today. They are quite = likely going to re-use their existing stuff while they may still be = interested in the end-to-end overload signaling. >=20 > 2) The overload signaling uses a piggybacking approach and it more or = less extends what is in the base specification. While the functionality = in the Diameter base specification is quite simplistic I am not = convinced that a minor add-on is not sufficient to solve the overload = problems we have seen today.=20 Ok. So you are leaning away from a specific overload control = application. I also recon you define a new Supported-Features AVP. Is = this anyhow aligned (or to be aligned) with 3GPP TS29.229 = Supported-Features AVP? - Jouni >=20 > As you mentioned, it is also stripped down. While each feature in the = OVL draft has a purpose it is nevertheless an optimization. There is a = tradeoff between adding benefits because of the optimizations (in the = amount of outsourcing of policy decisions from the Diameter server to = the Diameter client / Diameter agents) but there is also a price that is = paid for it in form of implementation cost (and license costs for IPR).=20= >=20 > Hope that this makes sense.=20 >=20 > Ciao > Hannes >=20 > On Jul 16, 2013, at 11:00 PM, Jouni Korhonen wrote: >=20 >> Hannes, >>=20 >> I got a quick question to understand these documents a bit better. >> What is the essential difference to e.g. draft-korhonen-dime-ovl >> apart from being a stripped down version of it more or less? >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >> On Jul 16, 2013, at 10:58 AM, Hannes Tschofenig = wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>> Hi all,=20 >>>=20 >>> I submitted a new approach for dealing with overload signaling in = Diameter.=20 >>>=20 >>> There are three documents:=20 >>>=20 >>> - ---------- >>>=20 >>> 1) Document with architectural principles and the information model >>> http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt >>>=20 >>> 2) The Diameter Load Balancing Application (DLBA) that specifically = provides the ability to exchange information for load balancing >>> http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt >>>=20 >>> 3) An mechanism to piggyback overload information from the Diameter = server to the Diameter client >>> = http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.tx= t >>>=20 >>> - ---------- >>>=20 >>> Probably the most important question is the following: What = motivated me to write these documents? The answer is pretty simple: I = was unhappy with the complexity introduced by the Tekelec proposal. I = wanted to create a simple foundation that can then be extended on a = need-by-need basis (as we do with other Diameter applications as well). = I was wondering how to simply it.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> PS: There are various reasons for the complexity in the Tekelec = solution proposal. I have captured some of those reasons (but not all) = in draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I = designed this solution approach in a modular fashion. For example, a = deployment may choose not to use the load balancing component (as such = it is optional) in case there is no load balancing between different = servers (for a given Diameter application) or in case load balancing is = accomplished using other techniques. (Needless to say that companies = have used load balancing in Diameter before this work has started.) >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>>=20 >>> iQEcBAEBCgAGBQJR5P0+AAoJEGhJURNOOiAtwQwH/AltiRpY0rOx0J4KMRM7ZELn >>> 13mfj4ctQrn8qTDtlS2xE0V40lGPzfstcbaWQiKhVtiZePB1kFusWYUXyhST6p0A >>> grXolprsL4vl+wZifGSkwny62/VJbNkjQ7coiiQrutcInUmXV8IUjsXntK7KjHfX >>> sh6r6pCVLNRwh8SaJzbxogItssb2+StpbDgDvryNFVL9TgYhdg8XMRCN/4RgqP7D >>> QObBw3/TBORrE3RAYmOo/hF3zPf6qiw8bePh51uW7Ve+hgEzYuuxYdByFFlkSEKq >>> sZUUXFMnrEs1sr+uzhLOtg5o9e1z9G78V9Ye1G5it+zU+qoBwdSr6m2/Dzpsqj8=3D >>> =3DdADz >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJR57ePAAoJEGhJURNOOiAtcvoH/0axsXl4bYcZYFFsu3W0NLh7 > +WXnd8zVV6o90kfbDKt+BltMOuF7DEGFs+m6Z5xPDD7uYm3AjLLgimMCYAUC4s7c > mnNiT9swRIoYgYz2/bqh7bQaH6QRWY1pIhlMb9IsJQXcSGHaCa2bkb4BINKLOG8V > tPfd40OOmm5cnNp4szyLdln1I8Rend9v9MgRiCF3JB30b/JaIi+QsC/l8KaSDxtc > nezkWotOtE1J1S1YeV09ViHTAzJOWqxHikilSMg0BKSh+WxcqZVY4lhNfSU2V2h1 > 7OzFXJJFYBVPhSvuoAweDtTqlU0dT9ATWxI37wTjouo4XwHPyUsRv1DSAKmXpyc=3D > =3D4goN > -----END PGP SIGNATURE----- From md3135@att.com Mon Jul 29 22:07:49 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 3F9DC21F9F96 for ; Mon, 29 Jul 2013 22:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTTEaPcPM5Dd for ; Mon, 29 Jul 2013 22:07:31 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id A550D21F9F5E for ; Mon, 29 Jul 2013 22:07:31 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 31a47f15.2aaadca20940.5430380.00-596.14964517.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 30 Jul 2013 05:07:31 +0000 (UTC) X-MXL-Hash: 51f74a132159fa83-a13b44a9a328de7c655f15713f6cc1c26ad4ca2f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 11a47f15.0.5430373.00-406.14964472.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 30 Jul 2013 05:07:30 +0000 (UTC) X-MXL-Hash: 51f74a126d367b99-badafdafb9ca0aa00faff00ad451b190305b948f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U57Soi002201; Tue, 30 Jul 2013 01:07:29 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U57H4l002149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 01:07:17 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jul 2013 05:07:11 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 01:07:11 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" Thread-Topic: Adopt draft-roach-dime-overload-ctrl as WG document Thread-Index: Ac6M4qSo8wZxr1H6SnGgWOqjoRv0Rw== Date: Tue, 30 Jul 2013 05:07:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.87.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=lkYLBpCC_S8A:10 a=6IiVxPTI6EcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Y12KDIHx7akA:10 a=jbvsCE7vce33gIndkf4A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=rgwzZBCpr0AA:10 a=5xCo_kXZCmwA:10] Subject: [Dime] Adopt draft-roach-dime-overload-ctrl as WG document 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, 30 Jul 2013 05:07:49 -0000 Good day, AT&T would like draft-roach-dime-overload-ctrl be adopted as a WG document = to which WG consensus changes can be made, at this meeting. I will be making recommendation on refinement of the scopes in a separate e= mail. Regards, Martin From md3135@att.com Mon Jul 29 22:23: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 7C3F121E8090 for ; Mon, 29 Jul 2013 22:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdOlGLTcpvpU for ; Mon, 29 Jul 2013 22:23:26 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 906FF21E804C for ; Mon, 29 Jul 2013 22:23:26 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id ecd47f15.492c0940.4080174.00-570.11243378.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 05:23:26 +0000 (UTC) X-MXL-Hash: 51f74dce29974e45-e2d10aa08c464d3e04c86294a5a2e87147ff86ec Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id dcd47f15.0.4080166.00-465.11243345.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 05:23:25 +0000 (UTC) X-MXL-Hash: 51f74dcd758d0ac4-4072bbfd3e4840ba98b79435684c39048b97a7b4 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U5NOgj008492; Tue, 30 Jul 2013 01:23:24 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U5NMGA008483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 01:23:22 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jul 2013 05:23:05 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 01:23:05 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" Thread-Topic: Scope refinement in draft-roach-dime-overload-ctrl Thread-Index: Ac6M5NszKoJ2mzJLQMKY5B9uMoYlqg== Date: Tue, 30 Jul 2013 05:23:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.87.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=lkYLBpCC_S8A:10 a=ovliyH3HtG4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=oqnlgUOcR8oA:10 a=cDp257d7W8cuwWqaj5IA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: [Dime] Scope refinement in draft-roach-dime-overload-ctrl 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, 30 Jul 2013 05:23:33 -0000 Greetings, AT&T recommendations the follow: 1. the Application-ID and Connection Scopes are the minimum set of scopes t= hat are mandatory to support for interoperability 2. the Session-Group Scope is required to be supported for diameter Session= s, and mandatory for complex deployments, as in 3GPP PCC. 3. the Session and the Host Scopes are NOT needed and should be removed fro= m the draft. 4. the Destination-Realm Scope is not needed in deployments with isolated (= separate) realms, therefore is not mandatory 5. the Destination-Host Scope is useful in some (not all) deployment scenar= ios, and should be optional 6. the discussion on "implicit"/base Scope should be put on hold till we ha= ve consensus on the refinement of the Scopes needed. Regards, Martin From hannes.tschofenig@gmx.net Mon Jul 29 22:48: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 82E0711E81B7 for ; Mon, 29 Jul 2013 22:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne0cYZo39jyS for ; Mon, 29 Jul 2013 22:48:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C0E9211E8174 for ; Mon, 29 Jul 2013 22:48:06 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MXZbS-1UXXyX2zVG-00WX7L for ; Tue, 30 Jul 2013 07:48:03 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 30 Jul 2013 07:48:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <551A28C2-0434-46E9-B964-44E9C309EF1F@gmx.net> References: To: "DOLLY, MARTIN C" X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:zVeWpExh1m5AXE6jskVOty/ZKDiCL3DJVdVUiSAnS1oTGdgMVbu rGicEL8iUbMV5MRaR/qTOGgs2EePulNbnRsHpgHvU127xKj2S1pCksqov5Kb7fjydRc0y2V fyTqZyb9j0hbLqFGqPp7SJkQ7B7Huwlr1TfrilLz7Ku5lBbXbdpLg6Is2bjdZmrMr9/1UhT Z6N/Wl0sJyOoy12lZSJ8A== Cc: "dime@ietf.org" Subject: Re: [Dime] Adopt draft-roach-dime-overload-ctrl as WG document 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, 30 Jul 2013 05:48:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Martin,=20 would you like to answer any of my questions from an earlier mail that = would allow the rest of the group to make an insightful decision (i.e., = one that is based on technical grounds)? Those would give us some = insight on how you envision how AT&T plans to deploy this work.=20 Here is my earlier mail:=20 http://www.ietf.org/mail-archive/web/dime/current/msg05813.html Ciao Hannes On Jul 30, 2013, at 7:07 AM, DOLLY, MARTIN C wrote: > Good day, >=20 > AT&T would like draft-roach-dime-overload-ctrl be adopted as a WG = document to which WG consensus changes can be made, at this meeting. >=20 > I will be making recommendation on refinement of the scopes in a = separate email. >=20 > Regards, >=20 > Martin > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR91ORAAoJEGhJURNOOiAtlWwIAISdTJbXnWPK6/sgDWFT0anU y7hVZHR3R5zmicTTRovv8MMOKI9HwecxjJbwpAkux0nZMybUZDe1Qfdvt7UmFJ2t tKV5LtpB/MSJwHz3mILK0tRtF+gejiLoFmqeesD/n636Avfy1mYaoI4avD6XCYys gVLE8KmiPxwiaxGewZtLo9ZOUVn7XJgeanO/hiMBd8pIlrfUSqUXs4Exfq1N92SK ztXUn3760GAJGJ8TvOaIwLejspddAtjufJ6cEm42BFbdqKYQFHTf8fufAQCLkkZw zkBVijyN1wS7LwSfVwDW81tNn9MEFPYgBxFIcZH6id6L4Z0Ge7CNgGDZt/mMerc=3D =3DIl8Z -----END PGP SIGNATURE----- From ben@nostrum.com Tue Jul 30 00:17:48 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 77BB411E81BF for ; Tue, 30 Jul 2013 00:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF2fCnl2KjON for ; Tue, 30 Jul 2013 00:17:48 -0700 (PDT) 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 E51BE11E81B9 for ; Tue, 30 Jul 2013 00:17:47 -0700 (PDT) Received: from dhcp-633e.meeting.ietf.org (dhcp-633e.meeting.ietf.org [130.129.99.62]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6U7HebZ084264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jul 2013 02:17:41 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Tue, 30 Jul 2013 09:17:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 130.129.99.62 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Scope refinement in draft-roach-dime-overload-ctrl 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, 30 Jul 2013 07:17:48 -0000 Hi Martin, One question, inline: Thanks! Ben. On Jul 30, 2013, at 7:23 AM, "DOLLY, MARTIN C" wrote: > Greetings, >=20 > AT&T recommendations the follow: >=20 > 1. the Application-ID and Connection Scopes are the minimum set of = scopes that are mandatory to support for interoperability >=20 > 2. the Session-Group Scope is required to be supported for diameter = Sessions, and mandatory for complex deployments, as in 3GPP PCC. Since you put these in separate line items, am I correct to assume you = intend "required to be supported" in line 2 to be different from = "mandatory to support" in line 1? >=20 > 3. the Session and the Host Scopes are NOT needed and should be = removed from the draft. >=20 > 4. the Destination-Realm Scope is not needed in deployments with = isolated (separate) realms, therefore is not mandatory >=20 > 5. the Destination-Host Scope is useful in some (not all) deployment = scenarios, and should be optional >=20 > 6. the discussion on "implicit"/base Scope should be put on hold till = we have consensus on the refinement of the Scopes needed. >=20 > Regards, >=20 > Martin From md3135@att.com Tue Jul 30 01:32: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 895D111E81C4 for ; Tue, 30 Jul 2013 01:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeRfXbeFZqqL for ; Tue, 30 Jul 2013 01:32:39 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8211E8133 for ; Tue, 30 Jul 2013 01:30:43 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 3b977f15.2aaaf2c3d940.4126456.00-576.11371119.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 08:30:43 +0000 (UTC) X-MXL-Hash: 51f779b300e4a189-c4aed14e033b82a353e3f9f50142e3840340e6c6 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b9977f15.0.4126426.00-397.11370725.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 08:30:22 +0000 (UTC) X-MXL-Hash: 51f7799e4ba71f50-4cb233fbee176a7e438f320b98f58f62e63df5ae Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U8UJnS017572; Tue, 30 Jul 2013 04:30:19 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U8UATE017528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 04:30:10 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jul 2013 08:30:00 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 04:29:59 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell Thread-Topic: Scope refinement in draft-roach-dime-overload-ctrl Thread-Index: Ac6M5NszKoJ2mzJLQMKY5B9uMoYlqgAMYteAAAYWqNA= Date: Tue, 30 Jul 2013 08:29:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=YonE0yZ436cA:10 a=TfyKhcmuAMkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=v_tHxrTxE80A:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=gxZvrgisAAAA:8 a=w4ov2x6VvXm7B8TaIvcA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=0MAqpqVwYqEA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a] X-AnalysisOut: [=Hz7IrDYlS0cA:10] Cc: "dime@ietf.org" Subject: Re: [Dime] Scope refinement in draft-roach-dime-overload-ctrl 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, 30 Jul 2013 08:32:46 -0000 Ben, To be clear on item #2, we see the Session-Group Scope as mandatory to impl= ement for equipment that support diameter sessions. WTS not all session ba= sed diameter interfaces/Applications, as the 3GPP Charging Ro interface, wo= uld need to use the Session-Group Scope. Regards, Martin -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, July 30, 2013 3:18 AM To: DOLLY, MARTIN C Cc: dime@ietf.org; Eric McMurry; TROTTIN, JEAN-JACQUES (JEAN-JACQUES) (jean= -jacques.trottin@alcatel-lucent.com) Subject: Re: Scope refinement in draft-roach-dime-overload-ctrl=20 Hi Martin, One question, inline: Thanks! Ben. On Jul 30, 2013, at 7:23 AM, "DOLLY, MARTIN C" wrote: > Greetings, >=20 > AT&T recommendations the follow: >=20 > 1. the Application-ID and Connection Scopes are the minimum set of scopes= that are mandatory to support for interoperability >=20 > 2. the Session-Group Scope is required to be supported for diameter Sessi= ons, and mandatory for complex deployments, as in 3GPP PCC. Since you put these in separate line items, am I correct to assume you inte= nd "required to be supported" in line 2 to be different from "mandatory to= support" in line 1? >=20 > 3. the Session and the Host Scopes are NOT needed and should be removed f= rom the draft. >=20 > 4. the Destination-Realm Scope is not needed in deployments with isolated= (separate) realms, therefore is not mandatory >=20 > 5. the Destination-Host Scope is useful in some (not all) deployment scen= arios, and should be optional >=20 > 6. the discussion on "implicit"/base Scope should be put on hold till we = have consensus on the refinement of the Scopes needed. >=20 > Regards, >=20 > Martin From ben@nostrum.com Tue Jul 30 01:40:56 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 2162421E80C1 for ; Tue, 30 Jul 2013 01:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrZsjHd2zG8T for ; Tue, 30 Jul 2013 01:40:54 -0700 (PDT) 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 B4C2521E80E1 for ; Tue, 30 Jul 2013 01:38:32 -0700 (PDT) Received: from dhcp-633e.meeting.ietf.org (dhcp-633e.meeting.ietf.org [130.129.99.62]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6U8cLxt095225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jul 2013 03:38:23 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Tue, 30 Jul 2013 10:38:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53614CB2-D8AF-4EB3-8B31-743D5C9D19AE@nostrum.com> References: To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 130.129.99.62 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Scope refinement in draft-roach-dime-overload-ctrl 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, 30 Jul 2013 08:40:56 -0000 Paraphrasing to check my own understanding: Session-Group scope would be optional to implement in general (i.e in = the IETF specs), but might be made mandatory by 3GPP (or other customer = SDOs) for certain interfaces? Would it make sense to for the IETF spec to say MAY in general, and = SHOULD for devices that support session-stateful applications? On Jul 30, 2013, at 10:29 AM, "DOLLY, MARTIN C" wrote: > Ben, >=20 > To be clear on item #2, we see the Session-Group Scope as mandatory to = implement for equipment that support diameter sessions. WTS not all = session based diameter interfaces/Applications, as the 3GPP Charging Ro = interface, would need to use the Session-Group Scope. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Tuesday, July 30, 2013 3:18 AM > To: DOLLY, MARTIN C > Cc: dime@ietf.org; Eric McMurry; TROTTIN, JEAN-JACQUES (JEAN-JACQUES) = (jean-jacques.trottin@alcatel-lucent.com) > Subject: Re: Scope refinement in draft-roach-dime-overload-ctrl=20 >=20 > Hi Martin, >=20 > One question, inline: >=20 > Thanks! >=20 > Ben. >=20 > On Jul 30, 2013, at 7:23 AM, "DOLLY, MARTIN C" wrote: >=20 >> Greetings, >>=20 >> AT&T recommendations the follow: >>=20 >> 1. the Application-ID and Connection Scopes are the minimum set of = scopes that are mandatory to support for interoperability >>=20 >> 2. the Session-Group Scope is required to be supported for diameter = Sessions, and mandatory for complex deployments, as in 3GPP PCC. >=20 > Since you put these in separate line items, am I correct to assume you = intend "required to be supported" in line 2 to be different from = "mandatory to support" in line 1? >=20 >>=20 >> 3. the Session and the Host Scopes are NOT needed and should be = removed from the draft. >>=20 >> 4. the Destination-Realm Scope is not needed in deployments with = isolated (separate) realms, therefore is not mandatory >>=20 >> 5. the Destination-Host Scope is useful in some (not all) deployment = scenarios, and should be optional >>=20 >> 6. the discussion on "implicit"/base Scope should be put on hold till = we have consensus on the refinement of the Scopes needed. >>=20 >> Regards, >>=20 >> Martin >=20 From md3135@att.com Tue Jul 30 02:01:40 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 8F51621F9E2B for ; Tue, 30 Jul 2013 02:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si9PSlVwp1dj for ; Tue, 30 Jul 2013 02:01:23 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE1F21E80C4 for ; Tue, 30 Jul 2013 02:00:05 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 59087f15.636ea940.4134411.00-536.11392423.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 09:00:05 +0000 (UTC) X-MXL-Hash: 51f780950c4e8fd6-47169da355bf2212f1ac8d1fa4e8083d195222eb Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 98087f15.0.4134407.00-319.11392331.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 08:59:53 +0000 (UTC) X-MXL-Hash: 51f78089030068c8-0e3ee44ed8f90550ae5415020ca8e72ebd2a38cb Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U8xrA8028689; Tue, 30 Jul 2013 04:59:53 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6U8xjRD028637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 04:59:45 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jul 2013 08:59:29 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 04:59:29 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell Thread-Topic: Scope refinement in draft-roach-dime-overload-ctrl Thread-Index: Ac6M5NszKoJ2mzJLQMKY5B9uMoYlqgAMYteAAAYWqND//+XVAIAAPYLg Date: Tue, 30 Jul 2013 08:59:29 +0000 Message-ID: References: <53614CB2-D8AF-4EB3-8B31-743D5C9D19AE@nostrum.com> In-Reply-To: <53614CB2-D8AF-4EB3-8B31-743D5C9D19AE@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.91.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=YonE0yZ436cA:10 a=TfyKhcmuAMkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=v_tHxrTxE80A:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=gxZvrgisAAAA:8 a=-sv7MTlADKXEz2oJbdAA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=0MAqpqVwYqEA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a] X-AnalysisOut: [=Hz7IrDYlS0cA:10] Cc: "dime@ietf.org" Subject: Re: [Dime] Scope refinement in draft-roach-dime-overload-ctrl 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, 30 Jul 2013 09:01:40 -0000 inline -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, July 30, 2013 4:38 AM To: DOLLY, MARTIN C Cc: dime@ietf.org; Eric McMurry; TROTTIN, JEAN-JACQUES (JEAN-JACQUES) (jean= -jacques.trottin@alcatel-lucent.com) Subject: Re: Scope refinement in draft-roach-dime-overload-ctrl=20 Paraphrasing to check my own understanding: Session-Group scope would be optional to implement in general (i.e in the I= ETF specs), but might be made mandatory by 3GPP (or other customer SDOs) fo= r certain interfaces? [MCD] - Yes Would it make sense to for the IETF spec to say MAY in general, and SHOULD = for devices that support session-stateful applications? [MCD] - Yes, that is reasonable On Jul 30, 2013, at 10:29 AM, "DOLLY, MARTIN C" wrote: > Ben, >=20 > To be clear on item #2, we see the Session-Group Scope as mandatory to im= plement for equipment that support diameter sessions. WTS not all session = based diameter interfaces/Applications, as the 3GPP Charging Ro interface, = would need to use the Session-Group Scope. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Tuesday, July 30, 2013 3:18 AM > To: DOLLY, MARTIN C > Cc: dime@ietf.org; Eric McMurry; TROTTIN, JEAN-JACQUES (JEAN-JACQUES) (je= an-jacques.trottin@alcatel-lucent.com) > Subject: Re: Scope refinement in draft-roach-dime-overload-ctrl=20 >=20 > Hi Martin, >=20 > One question, inline: >=20 > Thanks! >=20 > Ben. >=20 > On Jul 30, 2013, at 7:23 AM, "DOLLY, MARTIN C" wrote: >=20 >> Greetings, >>=20 >> AT&T recommendations the follow: >>=20 >> 1. the Application-ID and Connection Scopes are the minimum set of scope= s that are mandatory to support for interoperability >>=20 >> 2. the Session-Group Scope is required to be supported for diameter Sess= ions, and mandatory for complex deployments, as in 3GPP PCC. >=20 > Since you put these in separate line items, am I correct to assume you in= tend "required to be supported" in line 2 to be different from "mandatory = to support" in line 1? >=20 >>=20 >> 3. the Session and the Host Scopes are NOT needed and should be removed = from the draft. >>=20 >> 4. the Destination-Realm Scope is not needed in deployments with isolate= d (separate) realms, therefore is not mandatory >>=20 >> 5. the Destination-Host Scope is useful in some (not all) deployment sce= narios, and should be optional >>=20 >> 6. the discussion on "implicit"/base Scope should be put on hold till we= have consensus on the refinement of the Scopes needed. >>=20 >> Regards, >>=20 >> Martin >=20 From nh.jones01@gmail.com Wed Jul 31 00:06: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 CF2D321F9F59 for ; Wed, 31 Jul 2013 00:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvlUwg68hpcU for ; Wed, 31 Jul 2013 00:06:07 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80A21F9D6F for ; Wed, 31 Jul 2013 00:06:07 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id wz12so411793pbc.39 for ; Wed, 31 Jul 2013 00:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:x-priority:x-mailer :mime-version:content-transfer-encoding:content-type; bh=tIAfSIzNuNyoK1qAgk1viXtIswXB0ABWNxDuyJYuouI=; b=NWdbzD01JlKp3j+4UFNt8TMb+OUh1bBT88WGjVGBY/tu7m+XDseJP3VtHzqbpmddFy d9U36YIrjHEAdrZ4a1PnEgQKMJlyo4JmRrwANAyXOaPKDY0+vifnTWuF1VSm4lV6dUKq FXBMzCUB9d/kuS98S85n7/mPdrvFfivaWiCiJqtCn7P8Cd9I5jHpCxA4cm7LpFUDyLpy FdvTHE+T7wq6roEGxJnUPsnij8h0MBS/dqcDnnkTQb6EDAS81ykhW2NnayyQZ0NJyPLU 5PZobYVwsokda9w31Yj7OGkxsjbbes+mWcf5NFOPIokXXvQp6UweC75tFuFJoupbYjOx ld5A== X-Received: by 10.68.130.234 with SMTP id oh10mr78384435pbb.129.1375254366999; Wed, 31 Jul 2013 00:06:06 -0700 (PDT) Received: from queryhome.com (ec2-54-245-79-134.us-west-2.compute.amazonaws.com. [54.245.79.134]) by mx.google.com with ESMTPSA id a5sm328504pbw.4.2013.07.31.00.06.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 31 Jul 2013 00:06:06 -0700 (PDT) Date: Wed, 31 Jul 2013 07:06:05 +0000 To: dime@ietf.org From: Norah Jones Message-ID: X-Priority: 3 X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Subject: [Dime] Diameter Protocol Pcap Repository X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Norah Jones List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:06:07 -0000 Hi, Do we have any pcap repository of the Diameter Message any pointer... Thanks, Norah Jones From jouni.nospam@gmail.com Wed Jul 31 00:49: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 5311111E8165 for ; Wed, 31 Jul 2013 00:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR1ZIhN+NyBO for ; Wed, 31 Jul 2013 00:49:35 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 72C5211E80AD for ; Wed, 31 Jul 2013 00:49:34 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so458147pbc.32 for ; Wed, 31 Jul 2013 00:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ZToQiRK56yn4dwAlQvKj6302teqCRm3u0dVRkSgFqIU=; b=uXbLKE+r4ZMAOtM7sDIzAhRvKaK5C63LzS5bL7/Yp2cxTkMdgYKdNBXbVVX6RPnvWm bx3e9wSLdzbeJ7l8flz0TZZ6g7KzIby5x6F3N/P9D9LbIWuxCwUSKHs1Tc0r/LBsZXOI lY5rc0MkSgzEnkK6DC1MrVBLZjMGPxyRi2+MfQ6tQgrqMRJqZKe1zfrQeZ6rzQ79JKhY kNp/n+ZjBcodCVywI2coiPmSeQp9hSzLZzRDla5bSOtVlJZrulbCzHTG0Wm+3ON0WPUL SW7sPF7xZ8mn7H4zXby4GBbcEbxqk1HvCa1XfR3mkTJNoNJIrIsrfWrgtAZvIYfsl0ae ksRQ== X-Received: by 10.68.190.133 with SMTP id gq5mr21203224pbc.167.1375256974141; Wed, 31 Jul 2013 00:49:34 -0700 (PDT) Received: from ?IPv6:2001:df8::80:8d59:45ec:deba:6d47? ([2001:df8:0:80:8d59:45ec:deba:6d47]) by mx.google.com with ESMTPSA id ib9sm490741pbc.43.2013.07.31.00.49.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 00:49:33 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Jouni Korhonen X-Priority: 3 In-Reply-To: Date: Wed, 31 Jul 2013 10:49:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <948A951D-AD06-4F30-BFD8-FFDB11116F26@gmail.com> References: To: Norah Jones X-Mailer: Apple Mail (2.1508) Cc: dime@ietf.org Subject: Re: [Dime] Diameter Protocol Pcap Repository 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, 31 Jul 2013 07:49:36 -0000 After a very quick googling, check www.freediameter.net for captures. = For example: = http://www.freediameter.net/trac/browser/VirtualTestbed/mrb/capture.pcap?r= ev=3D9e5a3c884de6a635f786aea3e97e7e99f701a022 - Jouni On Jul 31, 2013, at 10:06 AM, Norah Jones wrote: > Hi,=20 >=20 > Do we have any pcap repository of the Diameter Message any pointer... >=20 > Thanks, > Norah Jones >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ietf-secretariat-reply@ietf.org Wed Jul 31 07:48: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 A0FC611E81AF for ; Wed, 31 Jul 2013 07:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2tT6NYyUaEP for ; Wed, 31 Jul 2013 07:48:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED93311E819A for ; Wed, 31 Jul 2013 07:48:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130731144852.30482.64867.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 07:48:52 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 31 Jul 2013 07:50:31 -0700 Subject: [Dime] Milestones changed for dime WG 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, 31 Jul 2013 14:48:53 -0000 Changed milestone "Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard.", set due date to January 2009 from January 2009. Changed milestone "Submit 'Diameter NAT Control Application' as DIME working group item", set due date to July 2009 from July 2009. Changed milestone "Submit 'Diameter Capabilities Update' as DIME working group item", set due date to July 2009 from July 2009. Changed milestone "Submit 'Diameter Extended NAPTR' as DIME working group item", set due date to July 2010 from July 2010. Changed milestone "Submit 'Realm-Based Redirection In Diameter' as DIME working group item", set due date to July 2010 from July 2010. Changed milestone "Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item", set due date to July 2010 from July 2010. Changed milestone "Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item", set due date to July 2010 from July 2010. Changed milestone "Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item", set due date to July 2010 from July 2010. Changed milestone "Submit 'Diameter IKEv2 PSK' as DIME working group item", set due date to July 2010 from July 2010. Changed milestone "Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard", set due date to August 2010 from August 2010. Changed milestone "Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard", set due date to August 2010 from August 2010. Changed milestone "Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard", set due date to August 2010 from August 2010. Changed milestone "Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item", set due date to August 2010 from August 2010. Changed milestone "Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard", set due date to March 2012 from March 2012, resolved as "Done". Changed milestone "Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard", resolved as "Done". Changed milestone "Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document", set due date to May 2012 from May 2012. Changed milestone "Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard", set due date to July 2012 from July 2012, resolved as "Done". Changed milestone "Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item", set due date to August 2012 from August 2012. Changed milestone "Submit a document on 'Protocol extension for bulk and group signaling' as a working group item", resolved as "Done". Changed milestone "Submit I-D 'Diameter Overload Control Requirements' as a working group document. To be Informational RFC", resolved as "Done". Changed milestone "Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC", set due date to December 2012 from December 2012. Changed milestone "Submit I-D 'Diameter Overload Control Requirements' to the IESG for consideration as a Informational", set due date to December 2012 from December 2012, resolved as "Done". Changed milestone "Submit I-D 'Diameter Overload Control' to the IESG for consideration as a Proposed Standard", set due date to March 2013 from March 2013. Changed milestone "Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard", set due date to August 2013 from August 2013. URL: http://datatracker.ietf.org/wg/dime/charter/ From jgunn6@csc.com Wed Jul 31 19:44: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 98CE411E80E4; Wed, 31 Jul 2013 19:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHEftSxkmjzj; Wed, 31 Jul 2013 19:44:50 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 00C8B21F943C; Wed, 31 Jul 2013 19:44:45 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-86.messagelabs.com!1375325081!42615511!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7416 invoked from network); 1 Aug 2013 02:44:42 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-13.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2013 02:44:42 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r712fPfs019607; Wed, 31 Jul 2013 22:41:25 -0400 In-Reply-To: References: To: Hannes Tschofenig MIME-Version: 1.0 X-KeepSent: EF5279F4:725A21DA-85257BBA:000EE30A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 31 Jul 2013 22:44:40 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/31/2013 10:38:12 PM, Serialize complete at 07/31/2013 10:38:12 PM Content-Type: multipart/alternative; boundary="=_alternative 000F239D85257BBA_=" Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] New Overload Solution Approach 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, 01 Aug 2013 02:44:55 -0000 This is a multipart message in MIME format. --=_alternative 000F239D85257BBA_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhbSBqdXN0IGNvbW1lbnRpbmcgb24gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCwgYW5kIHRo ZW4gb25seSBvbiB0aGUgDQpvdmVybG9hZCBwYXJ0LSBub3QgdGhlIGxvYWQgc2hhcmluZyBwYXJ0 Lg0KDQpUaGlzIGRyYWZ0IHNlZW1zIHRvIG1pc3MgdGhlIHBvaW50IHRoYXQsIGluIG9yZGVyIHRv IGF2b2lkIGNvbmdlc3Rpb24gDQpjb2xsYXBzZSwgdGhlIHNlcnZlciBtdXN0IGFzayB0aGUgY2xp ZW50IHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIA0Kc2VudCBCRUZPUkUgaXQgYmVj b21lcyBvdmVybG9hZGVkIC0gbm90IHdhaXQgdW50aWwgaXQgSVMgb3ZlcmxvYWRlZCB0byANCmVp dGhlciByZWplY3QgbWVzc2FnZXMgb3Igc2VuZCByZXF1ZXN0cyBmb3IgbG9hZCByZWR1Y3Rpb24g dG8gdGhlIGNsaWVudHMuDQoNCkkgYWdyZWUgdGhhdCBvdmVybG9hZCBjb25kaXRpb25zIGFyZSwg d2UgaG9wZSwgcmFyZSBldmVudHMuICBOb25lIHRoZSANCmxlc3MsIGl0IGlzIERVUklORyB0aGVz ZSBvdmVybG9hZCBldmVudHMgdGhhdCBhIHdvcmtpbmcgQUFBIHN5c3RlbSBtYXkgYmUgDQptb3N0 IGltcG9ydGFudC4NCg0KSW4gc2VjdGlvbiAzLCB0aGUgZHJhZnQgc2VlbXMgdG8gc3VnZ2VzdCB0 aGF0IGEgY2hvaWNlIHRvIOKAnHJldHVybiByZWplY3QgDQpyZXNwb25zZXMgd2l0aG91dCBlbmdh Z2luZyBpbiBoZWF2eSBhcHBsaWNhdGlvbiBzcGVjaWZpYyBwcm9jZXNzaW5n4oCdIGlzIGEgDQp2 aWFibGUgb3B0aW9uLiAgSXQgaXMgZXhhY3RseSB0aGUgcHJvY2Vzc2luZyBuZWVkZWQgdG8g4oCc cmV0dXJuIHJlamVjdCANCnJlc3BvbnNlc+KAnSB0aGF0IGxlYWRzIHRvIGNvbmdlc3Rpb24gY29s bGFwc2UsIGFzIGhhcyBiZWVuIHNob3duLCBhbW9uZyANCm90aGVyIHBsYWNlcywgaW4gdGhlIFNJ UCBPdmVybG9hZCBNb2RlbGluZy4gICAoSXQgbWF5IHNvbWV0aW1lcyBiZSBtb3JlIA0KZWZmZWN0 aXZlIHRvIGp1c3QgY29uc2lkZXIgYW4gb3ZlcmFsbCDigJxzZXJ2ZXIgb3ZlcmxvYWTigJ0sIHJh dGhlciB0aGFuIA0KY2FsY3VsYXRpbmcgc2VwYXJhdGUgb3ZlcmxvYWQgY29udHJvbHMgZm9yIGVh Y2gg4oCcYXBwbGljYXRpb27igJ0sIGV0Yy4pDQoNClNpbWlsYXJseSwgaW4gc2VjdGlvbiA0LjEs IHRoZSBkcmFmdCBzdWdnZXN0cyB0aGF0IHVzZSBvZiANCkRJQU1FVEVSX1RPT19CVVNZIGlzIGEg dmlhYmxlIGFwcHJvYWNoIHRvIGhhbmRsaW5nIG92ZXJsb2FkLiAgQXMgSSANCnVuZGVyc3RhbmQg aXQsIHRoaXMgYXBwcm9hY2ggc3VmZmVycyBmcm9tIHRoZSBzYW1lIHdlYWtuZXNzZXMgYXMgdGhl IFNJUCANCjUwMyByZXNwb25zZSAodyBvciB3L28g4oCccmV0cnkgYWZ0ZXLigJ0pLCBhbmQgd2ls bCByYXBpZGx5IGxlYWQgdG8gY29uZ2VzdGlvbiANCmNvbGxhcHNlIGluIHN1c3RhaW5lZCBvdmVy bG9hZHMuICBJbiBmYWN0LCBzZWN0aW9uIDUuMiBvZiB0aGUgcmVxdWlyZW1lbnRzIA0KZHJhZnQg Z29lcyBpbnRvIHNvbWUgZGVwdGggZXhwbGFpbmluZyB3aHkgRElBTUVURVJfVE9PX0JVU1kgaXMg bm90IGEgDQp2aWFibGUgc29sdXRpb24gdG8gRElNRSBPdmVybG9hZC4NCg0KVGhpcyBkcmFmdCBw cm9wb3NlcyBvbmx5IGZvdXIgb3B0aW9ucyBmb3IgT3ZlcmxvYWQgQ29udHJvbDoNCg0KTk9fT1ZF UkxPQUQgKCBkbyBub3QgcmVqZWN0IGFueSByZXF1ZXN0cykNCg0KSU5DUkVBU0lOR19PVkVSTE9B RCAoY2FsY3VsYXRlIHlvdXIgc2VuZGluZyByYXRlIG92ZXIgdGhlIGxhc3QgMTAgbWludXRlcywg DQphbmQgbGltaXQgeW91ciBuZXcgcmF0ZSB0byA1MCUgb2YgdGhhdCkNCg0KREVDUkVBU0lOR19P VkVSTE9BRCAoY2FsY3VsYXRlIHlvdXIgc2VuZGluZyByYXRlIG92ZXIgc2luY2UgdGhlIGxhc3Qg DQpvdmVybG9hZCBtZXNzYWdlLCBsaW1pdCB5b3VyIG5ldyByYXRlIHRvIDExMCUgb2YgdGhhdCkN Cg0KT1ZFUkxPQURFRCAoU1RPUCBzZW5kaW5nIGFueSByZXF1ZXN0cykNCg0KSW4gdGhlIGFic2Vu Y2Ugb2YgbGFiIHRlc3RzIG9yIHNpbXVsYXRpb24gcmVzdWx0cyB0byB0aGUgY29udHJhcnksIHRo aXMgDQpzZWVtcyB0byBoYXZlIHNldmVyYWwgc2hvcnRjb21pbmdzDQrCtyAgICAgICBJZiBhIGNs aWVudCBpcyBpbmFjdGl2ZSBtdWNoIG9mIHRoZSB0aW1lLCB0aGlzIGFwcHJvYWNoIG1heSBzaHV0 IA0KaXQgZG93biBjb21wbGV0ZWx5DQpvICAgICAgIElmIGEgcGFydGljdWxhciBjbGllbnQsIGZv ciB3aGF0ZXZlciByZWFzb25zLCB0cmFuc21pdHRlZCAwICh6ZXJvKSANCnJlcXVlc3RzIGluIHRo ZSBsYXN0IDEwIG1pbnV0ZXMsIHRoZSBJTkNSRUFTSU5HX09WRVJMT0FEIHdpbGwgcGluIGl0IGF0 IDAgDQoocHJvYmFibHkgdW5uZWNlc3NhcmlseSkgdW50aWwgdGhlcmUgaXMgTk9fT1ZFUkxPQUQu DQpvICAgICAgIElmIGEgcGFydGljdWxhciBjbGllbnQsIGZvciB3aGF0ZXZlciByZWFzb25zLCB0 cmFuc21pdHRlZCAwICh6ZXJvKSANCnJlcXVlc3RzIHNpbmNlIHRoZSBsYXN0IG92ZXJsb2FkIG1l c3NhZ2UsIHRoZSBERUNSRUFTSU5HX09WRVJMT0FEIHdpbGwgDQpzdGlsbCBwaW4gaXQgYXQgMCAg KDExMCUgb2YgIDAgPSAwKSAocHJvYmFibHkgdW5uZWNlc3NhcmlseSkuICBFYWNoIA0Kc3Vic2Vx dWVudCBERUNSRUFTSU5HX09WRVJMQU9EIHdpbGwgc3RpbGwgcGluIGl0IGF0IDAsIHVudGlsIHRo ZXJlIGlzIA0KTk9fT1ZFUkxPQUQNCsK3ICAgICAgIElmIG92ZXJsb2FkIGlzIGJ1aWxkaW5nIGdy YWR1YWxseSwgdGhlbiBhIDUwJSBjdXQgaXMgcHJvYmFibHkgDQpvdmVya2lsbCwgYW5kIGlzIGxp a2VseSB0byBsZWFkIHRvIChwb3NzaWJseSB1bnN0YWJsZSkgb3NjaWxsYXRpb25zLCBpbiANCnRo ZSBsb2FkIGF0IHRoZSBzZXJ2ZXIuICBJZiB0aGUgc2VydmVyIG9ubHkgTkVFRFMgYSAxMCUgcmVk dWN0aW9uIGluIGxvYWQgDQp0byBzdGF5IGluIHRoZSDigJxzdGFibGXigJ0gem9uZSwgdGhpcyBh cHByb2FjaCAgd2lsbCBuZWVkICA3IG1lc3NhZ2UgKGN1dCBieSANCjUwJSBvbmNlLCB0aGVuIGlu Y3JlYXNlIGJ5IDEwJSBzaXggdGltZXMgLSAgaWYgSSBhbSBjYWxjdWxhdGluZyBjb3JyZWN0bHkg DQotICBhc3N1bWluZyBhIGNvbnN0YW50IGxvYWQgY29taW5nIGludG8gdGhlIGNsaWVudCkgdG8g Z2V0IHRoZSBuZWVkZWQgDQpjb3JyZWN0aW9uLg0KwrcgICAgICAgSWYgb3ZlcmxvYWQgaXMgaW5j cmVhc2luZyByYXBpZGx5IHRoZSAxMCBtaW51dGUgbGVhZCB0aW1lIGlzIFdBWSANCnRvbyBsb25n ICggZm9yIHRoZSBraW5kcyBvZiDigJxldmVudHPigJ0gSSByZWd1bGFybHkgYW5hbHl6ZSDigJMg VG9ybmFkb3MsIA0KRWFydGhxdWFrZXMsIEJvc3RvbiBCb21iaW5nLSB0aGUgdmFyaW91cyBsb2Fk cyB0eXBpY2FsbHkgaW5jcmVhc2UgYnkgbW9yZSANCnRoYW4gYW4gb3JkZXIgb2YgbWFnbml0dWRl IGluIGxlc3MgdGhhbiA1IG1pbnV0ZXMuICBNYXliZSB0aGVyZSBpcyANCnNvbWV0aGluZyBhYm91 dCBESUFNRVRFUiB0aGF0IG1ha2VzIGl0IGltbXVuZSB0byB0aGVzZSBidXJzdHMsIGJ1dCBJIGRv dWJ0IA0KaXQpLg0KwrcgICAgICAgQXMgaGFzIGJlZW4gZGlzY3Vzc2VkIG1hbnkgdGltZXMgb24g Ym90aCBvbiB0aGlzIGxpc3QgYW5kIHRoZSBTSVAgDQpPdmVybG9hZCBsaXN0LCB0aGVyZSBhcmUg bWFueSBhcHBsaWNhdGlvbnMvYXJjaGl0ZWN0dXJlcy9jb250ZXh0cyBpbiB3aGljaCANCml0IGlz IGZhciBtb3JlIGVmZmVjdGl2ZSB0byBpbnN0cnVjdCB0aGUgY2xpZW50IHRvIGhvbm9yIGEgc3Bl Y2lmaWMgcmF0ZSANCihYIG1lc3NhZ2VzIHBlciBzZWNvbmQpIHJhdGhlciB0aGFuIGEgcGVyY2Vu dCByZWR1Y3Rpb24gKHdoZXRoZXIgYXMgYSANCnBlcmNlbnQgb2YgaW5jb21pbmcgbWVzc2FnZXMs IG9yIGFzIGEgcGVyY2VudCBvZiB5b3VyIHJlY2VudCBoaXN0b3JpY2FsIA0KcmF0ZSkuDQoNCnBh cnRpY2lwYXRpbmcgcmVtb3RlbHksDQpKYW5ldA0KDQoNCg0KRnJvbTogICBIYW5uZXMgVHNjaG9m ZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NClRvOiAgICAgZGltZUBpZXRmLm9yZw0K RGF0ZTogICAwNy8xNi8yMDEzIDAzOjU5IEFNDQpTdWJqZWN0OiAgICAgICAgW0RpbWVdIE5ldyBP dmVybG9hZCBTb2x1dGlvbiBBcHByb2FjaA0KU2VudCBieTogICAgICAgIGRpbWUtYm91bmNlc0Bp ZXRmLm9yZw0KDQoNCg0KLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDog U0hBNTEyDQoNCkhpIGFsbCwgDQoNCkkgc3VibWl0dGVkIGEgbmV3IGFwcHJvYWNoIGZvciBkZWFs aW5nIHdpdGggb3ZlcmxvYWQgc2lnbmFsaW5nIGluIA0KRGlhbWV0ZXIuIA0KDQpUaGVyZSBhcmUg dGhyZWUgZG9jdW1lbnRzOiANCg0KLSAtLS0tLS0tLS0tDQoNCjEpIERvY3VtZW50IHdpdGggYXJj aGl0ZWN0dXJhbCBwcmluY2lwbGVzIGFuZCB0aGUgaW5mb3JtYXRpb24gbW9kZWwNCmh0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC10c2Nob2ZlbmlnLWRpbWUtb3ZlcmxvYWQtYXJjaC0wMC50 eHQNCg0KMikgVGhlIERpYW1ldGVyIExvYWQgQmFsYW5jaW5nIEFwcGxpY2F0aW9uIChETEJBKSB0 aGF0IHNwZWNpZmljYWxseSANCnByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIGV4Y2hhbmdlIGluZm9y bWF0aW9uIGZvciBsb2FkIGJhbGFuY2luZw0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0 LXRzY2hvZmVuaWctZGltZS1kbGJhLTAwLnR4dA0KDQozKSBBbiBtZWNoYW5pc20gdG8gcGlnZ3li YWNrIG92ZXJsb2FkIGluZm9ybWF0aW9uIGZyb20gdGhlIERpYW1ldGVyIHNlcnZlciANCnRvIHRo ZSBEaWFtZXRlciBjbGllbnQNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10c2Nob2Zl bmlnLWRpbWUtb3ZlcmxvYWQtcGlnZ3liYWNraW5nLTAwLnR4dA0KDQoNCi0gLS0tLS0tLS0tLQ0K DQpQcm9iYWJseSB0aGUgbW9zdCBpbXBvcnRhbnQgcXVlc3Rpb24gaXMgdGhlIGZvbGxvd2luZzog V2hhdCBtb3RpdmF0ZWQgbWUgDQp0byB3cml0ZSB0aGVzZSBkb2N1bWVudHM/IFRoZSBhbnN3ZXIg aXMgcHJldHR5IHNpbXBsZTogSSB3YXMgdW5oYXBweSB3aXRoIA0KdGhlIGNvbXBsZXhpdHkgaW50 cm9kdWNlZCBieSB0aGUgVGVrZWxlYyBwcm9wb3NhbC4gSSB3YW50ZWQgdG8gY3JlYXRlIGEgDQpz aW1wbGUgZm91bmRhdGlvbiB0aGF0IGNhbiB0aGVuIGJlIGV4dGVuZGVkIG9uIGEgbmVlZC1ieS1u ZWVkIGJhc2lzIChhcyB3ZSANCmRvIHdpdGggb3RoZXIgRGlhbWV0ZXIgYXBwbGljYXRpb25zIGFz IHdlbGwpLiBJIHdhcyB3b25kZXJpbmcgaG93IHRvIA0Kc2ltcGx5IGl0LiANCg0KQ2lhbw0KSGFu bmVzDQoNClBTOiBUaGVyZSBhcmUgdmFyaW91cyByZWFzb25zIGZvciB0aGUgY29tcGxleGl0eSBp biB0aGUgVGVrZWxlYyBzb2x1dGlvbiANCnByb3Bvc2FsLiBJIGhhdmUgY2FwdHVyZWQgc29tZSBv ZiB0aG9zZSByZWFzb25zIChidXQgbm90IGFsbCkgaW4gDQpkcmFmdC10c2Nob2ZlbmlnLWRpbWUt b3ZlcmxvYWQtYXJjaC0wMC50eHQuIFRvIHJlZHVjZSBjb21wbGV4aXR5IEkgDQpkZXNpZ25lZCB0 aGlzIHNvbHV0aW9uIGFwcHJvYWNoIGluIGEgbW9kdWxhciBmYXNoaW9uLiBGb3IgZXhhbXBsZSwg YSANCmRlcGxveW1lbnQgbWF5IGNob29zZSBub3QgdG8gdXNlIHRoZSBsb2FkIGJhbGFuY2luZyBj b21wb25lbnQgKGFzIHN1Y2ggaXQgDQppcyBvcHRpb25hbCkgaW4gY2FzZSB0aGVyZSBpcyBubyBs b2FkIGJhbGFuY2luZyBiZXR3ZWVuIGRpZmZlcmVudCBzZXJ2ZXJzIA0KKGZvciBhIGdpdmVuIERp YW1ldGVyIGFwcGxpY2F0aW9uKSBvciBpbiBjYXNlIGxvYWQgYmFsYW5jaW5nIGlzIA0KYWNjb21w bGlzaGVkIHVzaW5nIG90aGVyIHRlY2huaXF1ZXMuIChOZWVkbGVzcyB0byBzYXkgdGhhdCBjb21w YW5pZXMgaGF2ZSANCnVzZWQgbG9hZCBiYWxhbmNpbmcgaW4gRGlhbWV0ZXIgYmVmb3JlIHRoaXMg d29yayBoYXMgc3RhcnRlZC4pDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJz aW9uOiBHbnVQRy9NYWNHUEcyIHYyLjAuMTkgKERhcndpbikNCkNvbW1lbnQ6IEdQR1Rvb2xzIC0g aHR0cDovL2dwZ3Rvb2xzLm9yZw0KDQppUUVjQkFFQkNnQUdCUUpSNVAwK0FBb0pFR2hKVVJOT09p QXR3UXdIL0FsdGlScFkwck94MEo0S01STTdaRUxuDQoxM21majRjdFFybjhxVER0bFMyeEUwVjQw bEdQemZzdGNiYVdRaUtoVnRpWmVQQjFrRnVzV1lVWHloU1Q2cDBBDQpnclhvbHByc0w0dmwrd1pp ZkdTa3dueTYyL1ZKYk5ralE3Y29paVFydXRjSW5VbVhWOElVanNYbnRLN0tqSGZYDQpzaDZyNnBD VkxOUndoOFNhSnpieG9nSXRzc2IyK1N0cGJEZ0R2cnlORlZMOVRnWWhkZzhYTVJDTi80UmdxUDdE DQpRT2JCdzMvVEJPUnJFM1JBWW1Pby9oRjN6UGY2cWl3OGJlUGg1MXVXN1ZlK2hnRXpZdXV4WWRC eUZGbGtTRUtxDQpzWlVVWEZNbnJFczFzcit1emhMT3RnNW85ZTF6OUc3OFY5WWUxRzVpdCt6VStx b0J3ZFNyNm0yL0R6cHNxajg9DQo9ZEFEeg0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWls aW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KDQoNCg== --=_alternative 000F239D85257BBA_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0ganVzdCBjb21tZW50aW5nIG9uIHRo ZSBhcmNoaXRlY3R1cmUNCmRvY3VtZW50LCBhbmQgdGhlbiBvbmx5IG9uIHRoZSBvdmVybG9hZCBw YXJ0LSBub3QgdGhlIGxvYWQgc2hhcmluZyBwYXJ0Ljxicj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhpcyBkcmFmdCBzZWVtcyB0byBtaXNzIHRoZSBwb2ludCB0 aGF0LA0KaW4gb3JkZXIgdG8gYXZvaWQgY29uZ2VzdGlvbiBjb2xsYXBzZSwgdGhlIHNlcnZlciBt dXN0IGFzayB0aGUgY2xpZW50IHRvDQpyZWR1Y2UgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBzZW50 IEJFRk9SRSBpdCBiZWNvbWVzIG92ZXJsb2FkZWQgLSBub3Qgd2FpdA0KdW50aWwgaXQgSVMgb3Zl cmxvYWRlZCB0byBlaXRoZXIgcmVqZWN0IG1lc3NhZ2VzIG9yIHNlbmQgcmVxdWVzdHMgZm9yIGxv YWQNCnJlZHVjdGlvbiB0byB0aGUgY2xpZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPkkgYWdyZWUgdGhhdCBvdmVybG9hZCBjb25kaXRpb25zIGFyZSwg d2UNCmhvcGUsIHJhcmUgZXZlbnRzLiAmbmJzcDtOb25lIHRoZSBsZXNzLCBpdCBpcyBEVVJJTkcg dGhlc2Ugb3ZlcmxvYWQgZXZlbnRzDQp0aGF0IGEgd29ya2luZyBBQUEgc3lzdGVtIG1heSBiZSBt b3N0IGltcG9ydGFudC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPkluIHNlY3Rpb24gMywgdGhlIGRyYWZ0IHNlZW1zIHRvIHN1Z2dlc3QNCnRoYXQgYSBjaG9p Y2UgdG8g4oCccmV0dXJuIHJlamVjdCByZXNwb25zZXMgd2l0aG91dCBlbmdhZ2luZyBpbiBoZWF2 eSBhcHBsaWNhdGlvbg0Kc3BlY2lmaWMgcHJvY2Vzc2luZ+KAnSBpcyBhIHZpYWJsZSBvcHRpb24u ICZuYnNwO0l0IGlzIGV4YWN0bHkgdGhlIHByb2Nlc3NpbmcNCm5lZWRlZCB0byDigJxyZXR1cm4g cmVqZWN0IHJlc3BvbnNlc+KAnSB0aGF0IGxlYWRzIHRvIGNvbmdlc3Rpb24gY29sbGFwc2UsDQph cyBoYXMgYmVlbiBzaG93biwgYW1vbmcgb3RoZXIgcGxhY2VzLCBpbiB0aGUgU0lQIE92ZXJsb2Fk IE1vZGVsaW5nLiAmbmJzcDsNCihJdCBtYXkgc29tZXRpbWVzIGJlIG1vcmUgZWZmZWN0aXZlIHRv IGp1c3QgY29uc2lkZXIgYW4gb3ZlcmFsbCDigJxzZXJ2ZXINCm92ZXJsb2Fk4oCdLCByYXRoZXIg dGhhbiBjYWxjdWxhdGluZyBzZXBhcmF0ZSBvdmVybG9hZCBjb250cm9scyBmb3IgZWFjaA0K4oCc YXBwbGljYXRpb27igJ0sIGV0Yy4pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5TaW1pbGFybHksIGluIHNlY3Rpb24gNC4xLCB0aGUgZHJhZnQgc3VnZ2VzdHMN CnRoYXQgdXNlIG9mIERJQU1FVEVSX1RPT19CVVNZIGlzIGEgdmlhYmxlIGFwcHJvYWNoIHRvIGhh bmRsaW5nIG92ZXJsb2FkLg0KJm5ic3A7QXMgSSB1bmRlcnN0YW5kIGl0LCB0aGlzIGFwcHJvYWNo IHN1ZmZlcnMgZnJvbSB0aGUgc2FtZSB3ZWFrbmVzc2VzDQphcyB0aGUgU0lQIDUwMyByZXNwb25z ZSAodyBvciB3L28g4oCccmV0cnkgYWZ0ZXLigJ0pLCBhbmQgd2lsbCByYXBpZGx5IGxlYWQNCnRv IGNvbmdlc3Rpb24gY29sbGFwc2UgaW4gc3VzdGFpbmVkIG92ZXJsb2Fkcy4gJm5ic3A7SW4gZmFj dCwgc2VjdGlvbiA1LjINCm9mIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgZ29lcyBpbnRvIHNvbWUg ZGVwdGggZXhwbGFpbmluZyB3aHkgRElBTUVURVJfVE9PX0JVU1kNCmlzIG5vdCBhIHZpYWJsZSBz b2x1dGlvbiB0byBESU1FIE92ZXJsb2FkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+VGhpcyBkcmFmdCBwcm9wb3NlcyBvbmx5IGZvdXIgb3B0aW9ucyBmb3IN Ck92ZXJsb2FkIENvbnRyb2w6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5OT19PVkVSTE9BRCAoIGRvIG5vdCByZWplY3QgYW55IHJlcXVlc3RzKTwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SU5DUkVBU0lOR19PVkVSTE9B RCAoY2FsY3VsYXRlIHlvdXIgc2VuZGluZw0KcmF0ZSBvdmVyIHRoZSBsYXN0IDEwIG1pbnV0ZXMs IGFuZCBsaW1pdCB5b3VyIG5ldyByYXRlIHRvIDUwJSBvZiB0aGF0KTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+REVDUkVBU0lOR19PVkVSTE9BRCAoY2FsY3Vs YXRlIHlvdXIgc2VuZGluZw0KcmF0ZSBvdmVyIHNpbmNlIHRoZSBsYXN0IG92ZXJsb2FkIG1lc3Nh Z2UsIGxpbWl0IHlvdXIgbmV3IHJhdGUgdG8gMTEwJQ0Kb2YgdGhhdCk8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPk9WRVJMT0FERUQgKFNUT1Agc2VuZGluZyBh bnkgcmVxdWVzdHMpPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5JbiB0aGUgYWJzZW5jZSBvZiBsYWIgdGVzdHMgb3Igc2ltdWxhdGlvbg0KcmVzdWx0cyB0byB0 aGUgY29udHJhcnksIHRoaXMgc2VlbXMgdG8gaGF2ZSBzZXZlcmFsIHNob3J0Y29taW5nczwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iU3ltYm9sIj7CtyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmDQphIGNsaWVudCBp cyBpbmFjdGl2ZSBtdWNoIG9mIHRoZSB0aW1lLCB0aGlzIGFwcHJvYWNoIG1heSBzaHV0IGl0IGRv d24gY29tcGxldGVseTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pm8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5JZg0KYSBwYXJ0aWN1bGFyIGNsaWVudCwgZm9yIHdoYXRldmVyIHJlYXNvbnMsIHRy YW5zbWl0dGVkIDAgKHplcm8pIHJlcXVlc3RzDQppbiB0aGUgbGFzdCAxMCBtaW51dGVzLCB0aGUg SU5DUkVBU0lOR19PVkVSTE9BRCB3aWxsIHBpbiBpdCBhdCAwIChwcm9iYWJseQ0KdW5uZWNlc3Nh cmlseSkgdW50aWwgdGhlcmUgaXMgTk9fT1ZFUkxPQUQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+byAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmDQphIHBhcnRpY3VsYXIgY2xpZW50LCBmb3Ig d2hhdGV2ZXIgcmVhc29ucywgdHJhbnNtaXR0ZWQgMCAoemVybykgcmVxdWVzdHMNCnNpbmNlIHRo ZSBsYXN0IG92ZXJsb2FkIG1lc3NhZ2UsIHRoZSBERUNSRUFTSU5HX09WRVJMT0FEIHdpbGwgc3Rp bGwgcGluDQppdCBhdCAwICZuYnNwOygxMTAlIG9mICZuYnNwOzAgPSAwKSAocHJvYmFibHkgdW5u ZWNlc3NhcmlseSkuICZuYnNwO0VhY2gNCnN1YnNlcXVlbnQgREVDUkVBU0lOR19PVkVSTEFPRCB3 aWxsIHN0aWxsIHBpbiBpdCBhdCAwLCB1bnRpbCB0aGVyZSBpcyBOT19PVkVSTE9BRDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iU3ltYm9sIj7CtyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmDQpvdmVybG9hZCBpcyBi dWlsZGluZyBncmFkdWFsbHksIHRoZW4gYSA1MCUgY3V0IGlzIHByb2JhYmx5IG92ZXJraWxsLCBh bmQNCmlzIGxpa2VseSB0byBsZWFkIHRvIChwb3NzaWJseSB1bnN0YWJsZSkgb3NjaWxsYXRpb25z LCBpbiB0aGUgbG9hZCBhdCB0aGUNCnNlcnZlci4gJm5ic3A7SWYgdGhlIHNlcnZlciBvbmx5IE5F RURTIGEgMTAlIHJlZHVjdGlvbiBpbiBsb2FkIHRvIHN0YXkNCmluIHRoZSDigJxzdGFibGXigJ0g em9uZSwgdGhpcyBhcHByb2FjaCAmbmJzcDt3aWxsIG5lZWQgJm5ic3A7NyBtZXNzYWdlIChjdXQN CmJ5IDUwJSBvbmNlLCB0aGVuIGluY3JlYXNlIGJ5IDEwJSBzaXggdGltZXMgLSAmbmJzcDtpZiBJ IGFtIGNhbGN1bGF0aW5nDQpjb3JyZWN0bHkgLSAmbmJzcDthc3N1bWluZyBhIGNvbnN0YW50IGxv YWQgY29taW5nIGludG8gdGhlIGNsaWVudCkgdG8gZ2V0DQp0aGUgbmVlZGVkIGNvcnJlY3Rpb24u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJTeW1ib2wiPsK3ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SWYNCm92ZXJs b2FkIGlzIGluY3JlYXNpbmcgcmFwaWRseSB0aGUgMTAgbWludXRlIGxlYWQgdGltZSBpcyBXQVkg dG9vIGxvbmcNCiggZm9yIHRoZSBraW5kcyBvZiDigJxldmVudHPigJ0gSSByZWd1bGFybHkgYW5h bHl6ZSDigJMgVG9ybmFkb3MsIEVhcnRocXVha2VzLA0KQm9zdG9uIEJvbWJpbmctIHRoZSB2YXJp b3VzIGxvYWRzIHR5cGljYWxseSBpbmNyZWFzZSBieSBtb3JlIHRoYW4gYW4gb3JkZXINCm9mIG1h Z25pdHVkZSBpbiBsZXNzIHRoYW4gNSBtaW51dGVzLiAmbmJzcDtNYXliZSB0aGVyZSBpcyBzb21l dGhpbmcgYWJvdXQNCkRJQU1FVEVSIHRoYXQgbWFrZXMgaXQgaW1tdW5lIHRvIHRoZXNlIGJ1cnN0 cywgYnV0IEkgZG91YnQgaXQpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iU3ltYm9s Ij7CtyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPkFzDQpoYXMgYmVlbiBkaXNjdXNzZWQgbWFueSB0aW1lcyBvbiBib3RoIG9uIHRo aXMgbGlzdCBhbmQgdGhlIFNJUCBPdmVybG9hZA0KbGlzdCwgdGhlcmUgYXJlIG1hbnkgYXBwbGlj YXRpb25zL2FyY2hpdGVjdHVyZXMvY29udGV4dHMgaW4gd2hpY2ggaXQgaXMNCmZhciBtb3JlIGVm ZmVjdGl2ZSB0byBpbnN0cnVjdCB0aGUgY2xpZW50IHRvIGhvbm9yIGEgc3BlY2lmaWMgcmF0ZSAo WCBtZXNzYWdlcw0KcGVyIHNlY29uZCkgcmF0aGVyIHRoYW4gYSBwZXJjZW50IHJlZHVjdGlvbiAo d2hldGhlciBhcyBhIHBlcmNlbnQgb2YgaW5jb21pbmcNCm1lc3NhZ2VzLCBvciBhcyBhIHBlcmNl bnQgb2YgeW91ciByZWNlbnQgaGlzdG9yaWNhbCByYXRlKS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnBhcnRpY2lwYXRpbmcgcmVtb3RlbHksPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5KYW5ldDwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNl cmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5IYW5uZXMgVHNjaG9mZW5pZyAmbHQ7aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldCZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFj ZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRpbWVAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MDcvMTYvMjAxMyAwMzo1OSBBTTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bRGltZV0gTmV3IE92ZXJsb2Fk DQpTb2x1dGlvbiBBcHByb2FjaDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kaW1lLWJvdW5jZXNAaWV0Zi5v cmc8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08YnI+DQpIYXNoOiBTSEE1 MTI8YnI+DQo8YnI+DQpIaSBhbGwsIDxicj4NCjxicj4NCkkgc3VibWl0dGVkIGEgbmV3IGFwcHJv YWNoIGZvciBkZWFsaW5nIHdpdGggb3ZlcmxvYWQgc2lnbmFsaW5nIGluIERpYW1ldGVyLg0KPGJy Pg0KPGJyPg0KVGhlcmUgYXJlIHRocmVlIGRvY3VtZW50czogPGJyPg0KPGJyPg0KLSAtLS0tLS0t LS0tPGJyPg0KPGJyPg0KMSkgRG9jdW1lbnQgd2l0aCBhcmNoaXRlY3R1cmFsIHByaW5jaXBsZXMg YW5kIHRoZSBpbmZvcm1hdGlvbiBtb2RlbDxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10c2Nob2ZlbmlnLWRpbWUtb3ZlcmxvYWQtYXJjaC0w MC50eHQiPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRz Y2hvZmVuaWctZGltZS1vdmVybG9hZC1hcmNoLTAwLnR4dDwvZm9udD48L3R0PjwvYT48dHQ+PGZv bnQgc2l6ZT0yPjxicj4NCjxicj4NCjIpIFRoZSBEaWFtZXRlciBMb2FkIEJhbGFuY2luZyBBcHBs aWNhdGlvbiAoRExCQSkgdGhhdCBzcGVjaWZpY2FsbHkgcHJvdmlkZXMNCnRoZSBhYmlsaXR5IHRv IGV4Y2hhbmdlIGluZm9ybWF0aW9uIGZvciBsb2FkIGJhbGFuY2luZzxicj4NCjwvZm9udD48L3R0 PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10c2Nob2ZlbmlnLWRpbWUt ZGxiYS0wMC50eHQiPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXRzY2hvZmVuaWctZGltZS1kbGJhLTAwLnR4dDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCjxicj4NCjMpIEFuIG1lY2hhbmlzbSB0byBwaWdneWJhY2sgb3ZlcmxvYWQg aW5mb3JtYXRpb24gZnJvbSB0aGUgRGlhbWV0ZXIgc2VydmVyDQp0byB0aGUgRGlhbWV0ZXIgY2xp ZW50PGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXRzY2hvZmVuaWctZGltZS1vdmVybG9hZC1waWdneWJhY2tpbmctMDAudHh0Ij48dHQ+PGZv bnQgc2l6ZT0yPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10c2Nob2ZlbmlnLWRpbWUt b3ZlcmxvYWQtcGlnZ3liYWNraW5nLTAwLnR4dDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6 ZT0yPjxicj4NCjxicj4NCi0gLS0tLS0tLS0tLTxicj4NCjxicj4NClByb2JhYmx5IHRoZSBtb3N0 IGltcG9ydGFudCBxdWVzdGlvbiBpcyB0aGUgZm9sbG93aW5nOiBXaGF0IG1vdGl2YXRlZCBtZQ0K dG8gd3JpdGUgdGhlc2UgZG9jdW1lbnRzPyBUaGUgYW5zd2VyIGlzIHByZXR0eSBzaW1wbGU6IEkg d2FzIHVuaGFwcHkgd2l0aA0KdGhlIGNvbXBsZXhpdHkgaW50cm9kdWNlZCBieSB0aGUgVGVrZWxl YyBwcm9wb3NhbC4gSSB3YW50ZWQgdG8gY3JlYXRlIGENCnNpbXBsZSBmb3VuZGF0aW9uIHRoYXQg Y2FuIHRoZW4gYmUgZXh0ZW5kZWQgb24gYSBuZWVkLWJ5LW5lZWQgYmFzaXMgKGFzDQp3ZSBkbyB3 aXRoIG90aGVyIERpYW1ldGVyIGFwcGxpY2F0aW9ucyBhcyB3ZWxsKS4gSSB3YXMgd29uZGVyaW5n IGhvdyB0bw0Kc2ltcGx5IGl0LiA8YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzPGJyPg0KPGJy Pg0KUFM6IFRoZXJlIGFyZSB2YXJpb3VzIHJlYXNvbnMgZm9yIHRoZSBjb21wbGV4aXR5IGluIHRo ZSBUZWtlbGVjIHNvbHV0aW9uDQpwcm9wb3NhbC4gSSBoYXZlIGNhcHR1cmVkIHNvbWUgb2YgdGhv c2UgcmVhc29ucyAoYnV0IG5vdCBhbGwpIGluIGRyYWZ0LXRzY2hvZmVuaWctZGltZS1vdmVybG9h ZC1hcmNoLTAwLnR4dC4NClRvIHJlZHVjZSBjb21wbGV4aXR5IEkgZGVzaWduZWQgdGhpcyBzb2x1 dGlvbiBhcHByb2FjaCBpbiBhIG1vZHVsYXIgZmFzaGlvbi4NCkZvciBleGFtcGxlLCBhIGRlcGxv eW1lbnQgbWF5IGNob29zZSBub3QgdG8gdXNlIHRoZSBsb2FkIGJhbGFuY2luZyBjb21wb25lbnQN CihhcyBzdWNoIGl0IGlzIG9wdGlvbmFsKSBpbiBjYXNlIHRoZXJlIGlzIG5vIGxvYWQgYmFsYW5j aW5nIGJldHdlZW4gZGlmZmVyZW50DQpzZXJ2ZXJzIChmb3IgYSBnaXZlbiBEaWFtZXRlciBhcHBs aWNhdGlvbikgb3IgaW4gY2FzZSBsb2FkIGJhbGFuY2luZyBpcw0KYWNjb21wbGlzaGVkIHVzaW5n IG90aGVyIHRlY2huaXF1ZXMuIChOZWVkbGVzcyB0byBzYXkgdGhhdCBjb21wYW5pZXMgaGF2ZQ0K dXNlZCBsb2FkIGJhbGFuY2luZyBpbiBEaWFtZXRlciBiZWZvcmUgdGhpcyB3b3JrIGhhcyBzdGFy dGVkLik8YnI+DQo8YnI+DQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLTxicj4NClZlcnNp b246IEdudVBHL01hY0dQRzIgdjIuMC4xOSAoRGFyd2luKTxicj4NCkNvbW1lbnQ6IEdQR1Rvb2xz IC0gPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwOi8vZ3BndG9vbHMub3JnLz48dHQ+PGZvbnQgc2l6 ZT0yPmh0dHA6Ly9ncGd0b29scy5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQo8YnI+DQppUUVjQkFFQkNnQUdCUUpSNVAwK0FBb0pFR2hKVVJOT09pQXR3UXdIL0FsdGlS cFkwck94MEo0S01STTdaRUxuPGJyPg0KMTNtZmo0Y3RRcm44cVREdGxTMnhFMFY0MGxHUHpmc3Rj YmFXUWlLaFZ0aVplUEIxa0Z1c1dZVVh5aFNUNnAwQTxicj4NCmdyWG9scHJzTDR2bCt3WmlmR1Nr d255NjIvVkpiTmtqUTdjb2lpUXJ1dGNJblVtWFY4SVVqc1hudEs3S2pIZlg8YnI+DQpzaDZyNnBD VkxOUndoOFNhSnpieG9nSXRzc2IyK1N0cGJEZ0R2cnlORlZMOVRnWWhkZzhYTVJDTi80UmdxUDdE PGJyPg0KUU9iQnczL1RCT1JyRTNSQVltT28vaEYzelBmNnFpdzhiZVBoNTF1VzdWZStoZ0V6WXV1 eFlkQnlGRmxrU0VLcTxicj4NCnNaVVVYRk1uckVzMXNyK3V6aExPdGc1bzllMXo5Rzc4VjlZZTFH NWl0K3pVK3FvQndkU3I2bTIvRHpwc3FqOD08YnI+DQo9ZEFEejxicj4NCi0tLS0tRU5EIFBHUCBT SUdOQVRVUkUtLS0tLTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KRGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQpEaU1FQGlldGYub3JnPGJyPg0K PC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RpbWU+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RpbWU8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90 dD4NCjxicj4NCg== --=_alternative 000F239D85257BBA_=--