From nobody Fri Aug 1 03:58:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530F91A0A87 for ; Fri, 1 Aug 2014 03:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRjWoZHVI6sb for ; Fri, 1 Aug 2014 03:58:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6B01A0A82 for ; Fri, 1 Aug 2014 03:58:26 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id F090518C733; Fri, 1 Aug 2014 12:58:24 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D329C4C06B; Fri, 1 Aug 2014 12:58:24 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 12:58:24 +0200 From: To: Steve Donovan , "dime@ietf.org" , "Nirav Salot (nsalot)" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrPkUKkwluafl4k6XkejzZpuF5Zu7GrAAgAB6Zfg= Date: Fri, 1 Aug 2014 10:58:24 +0000 Message-ID: <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> References: <53DA9EA2.4010906@usdonovans.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6jqjx92pvkh7ceh3vosxad661406890698315emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.91819 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CzqZILwyYdtd9K3KzEwsHxha8vg Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 10:58:30 -0000 --_000_6jqjx92pvkh7ceh3vosxad661406890698315emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Steve, I agree with Nirav's view. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I don=92t agree to include identity of the DOIC node that s= ends the report, into the realm reports. In my view, the issue mentioned below =96 of two agents not 100% synchroniz= e w.r.t the realm-report =96 is the related to "how agents synchronized bet= ween themselves" and since that is not standardized we should not be develo= ping protocol solution for the case which occurs due to this out-of-standar= ds solution. Besides, I don=92t see any issue due to slight miss-synchronization of the = realm-reports between two agents since they should still represent the real= m load more or less accurately. Also if the agents are not synchronized and if they are playing the role of= DOIC reacting node then they will apply abatement algorithm based on diffe= rent values (for the same realm). So it does not matter if the client does = the same. Finally, I don=92t see any value-add of using the "identity of the node tha= t sends the realm-report" to discard the other report related to the same r= ealm. In other words, this same logic can be achieved using sequence-number= s as well, i.e. when the overload-report of an realm is active, the client = is going to ignore all the reports of the same realm which has lower sequen= ce number value. So in essence, when two agents are sending realm-reports, = one of the reports is automatically ignored by the client if their sequence= numbers differ. So the outcome without including the "identity if the node= that sends realm report" is same as >The effect should be that the reacting node will accept a realm report fro= m anyone when there is no active OLR for the realm but it will only listen = to one reporting node when it has an active report. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 1:23 AM To: dime@ietf.org Subject: [Dime] DOIC issue #58 Proposal All, Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of = a reporting node for realm-routed-request reports, reacting nodes may recei= ve in different answer messages different realm-routed-request type OLRs in= serted by the different reporting nodes. Although it is expected that the d= ifferent reporting nodes report more or less the same content, it cannot be= expected that reports are 100% synchronized. Especially sequence numbers m= ay differ. To allow reacting nodes correctly detect outdates/replays/freshn= ess of OLRs in this scenario, it is proposed that realm-routed-request type= OLRs are extended to contain the Diameter Identity of the reporting node t= hat inserted the realm-routed-request type OLR. (e.g. as already proposed i= n draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-req= uest type OLRs to answer messages MUST also insert their Diameter Identity.= Reacting nodes MUST take the Diameter Identity received within the OLR int= o account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report. This would be an optional AVP only required = for realm reports. It would not be required for host reports as the identi= ty of the sender of the host report is implicitly defined by the origin-hos= t in the answer message. I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state. = To this end I propose that we add wording that for the duration of a realm = report, the reacting node only listens for updates to the realm report from= from the DOIC node that sent the realm report that resulted in the realm O= CS being stored. The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report. Steve ___________________________________________________________________________= ______________________________________________ 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_6jqjx92pvkh7ceh3vosxad661406890698315emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 
Hi Steve,

I agree with Nirav's view.=20

Regards,

Lionel=20

Envoy=E9 depuis mon Sony Xperia SP d'Orange

---- Nirav Salot (nsalot) a =E9crit ----

Steve,

 

For this issue, I don= =92t agree to include identity of the DOIC node that sends the report, into= the realm reports.

 

In my view, the issue m= entioned below =96 of two agents not 100% synchronize w.r.t the realm-repor= t =96 is the related to "how agents synchronized between themselves&qu= ot; and since that is not standardized we should not be developing protocol so= lution for the case which occurs due to this out-of-standards solution.

 

Besides, I don=92t see = any issue due to slight miss-synchronization of the realm-reports between t= wo agents since they should still represent the realm load more or less accurately.

 

Also if the agents are = not synchronized and if they are playing the role of DOIC reacting node the= n they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the = same.

 

Finally, I don=92t see = any value-add of using the "identity of the node that sends the realm-= report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as = well, i.e. when the overload-report of an realm is active, the client is go= ing to ignore all the reports of the same realm which has lower sequence nu= mber value. So in essence, when two agents are sending realm-reports, one of the reports is automatically = ignored by the client if their sequence numbers differ. So the outcome with= out including the "identity if the node that sends realm report" = is same as

>The effect should be that the reacting node will= accept a realm report from anyone when there is no active OLR for the real= m but it will only listen to one reporting node when it has an active repor= t.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: dime@ietf.org
Subject: [Dime] DOIC issue #58 Proposal

 

All,

Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. 

Ulrich proposes one aspect of what is required in the issue description:

"In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report m= ore or less the same content, it cannot be expected that reports are 100% s= ynchronized. Especially sequence numbers may differ. To allow reacting node= s correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OL= Rs are extended to contain the Diameter Identity of the reporting node that= inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea= lm-routed-request type OLRs to answer messages MUST also insert their Diame= ter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order t= o detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report.  This would be an optional AVP only requ= ired for realm reports.  It would not be required for host reports as = the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state.&n= bsp; To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the real= m report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report.

Steve


______________________________________________________________________=
___________________________________________________

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_6jqjx92pvkh7ceh3vosxad661406890698315emailandroidcom_-- From nobody Fri Aug 1 07:08:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE60D1A0653 for ; Fri, 1 Aug 2014 07:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dm-MmJ6H0_d for ; Fri, 1 Aug 2014 07:08:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD171A004A for ; Fri, 1 Aug 2014 07:08:32 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s71E8RbP087954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 09:08:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53DB2782.4080909@gmail.com> Date: Fri, 1 Aug 2014 09:08:27 -0500 X-Mao-Original-Outgoing-Id: 428594907.281579-02d5a852570e7f16f488570759c36207 Content-Transfer-Encoding: quoted-printable Message-Id: <562909D4-B02B-4856-9B4A-90648DC1B8D3@nostrum.com> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> <53DAB779.5000303@gmail.com> <5EFE4D16-4C2E-4583-8D40-5C70F9FE1FE7@nostrum.com> <53DB2782.4080909@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4LCiBAS42-SrRdwub_hg4Ef60qk Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 14:08:38 -0000 On Aug 1, 2014, at 12:37 AM, Jouni Korhonen = wrote: >>>=20 >>> A "node" as a DOICable relay can do DOIC stuff to _any_ application = within certain limits. If the "DOIC stuff" is just applying the = abatement, then that is OK for _any_ application depending on the = abatement algorithm. If the "DOIC stuff" is beyond that e.g. = adding/removing DOIC AVPs then the DOICable relay has to be application = aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble = with applications whose messages' CCF has no *[AVP]. >>=20 >> Adam did a survey way back when, and found that such applications are = vanishingly rare. (Was it just the watchdog application?). Hopefully = people won't try to define new applications without *[AVP]/ >=20 > I know. *[AVP] was just an example. Another example would be new = applications that embed DOIC as a part of their formal CCF and there = even changing the location of the DOIC AVP could break the CCF check. We could offer guidance to not make the DOIC AVPs fixed. OTOH, I see there might be some issues with interfering with other fixed = position AVPs in the CCF, if an relay that doesn't know the CCF changes = their position by inserting DOIC AVPs. We could recommend such relays = insert at the end, but there are probably efficiency reasons to add them = close to the front. I guess we could say "add close to the top if you = understand the CCF, otherwise add at the end." To be clear, I think the most common use of DOIC at agents would be at = proxies, so this becomes an edge case. It's just an edge case I think we = need to support.= From nobody Fri Aug 1 07:50:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0D1A0073 for ; Fri, 1 Aug 2014 07:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eANZaJk55sBr for ; Fri, 1 Aug 2014 07:50:09 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.162]) by ietfa.amsl.com (Postfix) with ESMTP id 776151A005E for ; Fri, 1 Aug 2014 07:50:08 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 10:49:46 -0400 From: Dave Dolson To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" , "Nirav Salot (nsalot)" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrP2S1BdX5+SRWUCPQPKvS6NNgJu7fzwAgABY3gD///wqYA== Date: Fri, 1 Aug 2014 14:49:46 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> In-Reply-To: <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.111] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830A76516wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9Bk6upqeW3o44e92r2U5crkvfYU Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 14:50:13 -0000 --_000_E8355113905631478EFF04F5AA706E9830A76516wtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe Nirav's view requires all hosts in a realm to be the same vendor = and use a proprietary communication protocol to synchronize the host report= . Or, if a multiple (redundant or active-active) load-balancing agents are = generating the report, they must similarly be synchronized. Is seems like including the host name per Ulrich's suggestion is a simple w= ay of avoiding proprietary mechanisms or coupling between hosts and agents. In some applications, the hosts can be completely decoupled (agnostic about= each other). I think it would be poor to add a synchronization requirement= just to support DOIC. -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Friday, August 01, 2014 6:58 AM To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree with Nirav's view. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. In my view, the issue mentioned below - of two agents not 100% synchronize = w.r.t the realm-report - is the related to "how agents synchronized between= themselves" and since that is not standardized we should not be developing= protocol solution for the case which occurs due to this out-of-standards s= olution. Besides, I don't see any issue due to slight miss-synchronization of the re= alm-reports between two agents since they should still represent the realm = load more or less accurately. Also if the agents are not synchronized and if they are playing the role of= DOIC reacting node then they will apply abatement algorithm based on diffe= rent values (for the same realm). So it does not matter if the client does = the same. Finally, I don't see any value-add of using the "identity of the node that = sends the realm-report" to discard the other report related to the same rea= lm. In other words, this same logic can be achieved using sequence-numbers = as well, i.e. when the overload-report of an realm is active, the client is= going to ignore all the reports of the same realm which has lower sequence= number value. So in essence, when two agents are sending realm-reports, on= e of the reports is automatically ignored by the client if their sequence n= umbers differ. So the outcome without including the "identity if the node t= hat sends realm report" is same as >The effect should be that the reacting node will accept a realm report fro= m anyone when there is no active OLR for the realm but it will only listen = to one reporting node when it has an active report. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 1:23 AM To: dime@ietf.org Subject: [Dime] DOIC issue #58 Proposal All, Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of = a reporting node for realm-routed-request reports, reacting nodes may recei= ve in different answer messages different realm-routed-request type OLRs in= serted by the different reporting nodes. Although it is expected that the d= ifferent reporting nodes report more or less the same content, it cannot be= expected that reports are 100% synchronized. Especially sequence numbers m= ay differ. To allow reacting nodes correctly detect outdates/replays/freshn= ess of OLRs in this scenario, it is proposed that realm-routed-request type= OLRs are extended to contain the Diameter Identity of the reporting node t= hat inserted the realm-routed-request type OLR. (e.g. as already proposed i= n draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-req= uest type OLRs to answer messages MUST also insert their Diameter Identity.= Reacting nodes MUST take the Diameter Identity received within the OLR int= o account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report. This would be an optional AVP only required = for realm reports. It would not be required for host reports as the identi= ty of the sender of the host report is implicitly defined by the origin-hos= t in the answer message. I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state. = To this end I propose that we add wording that for the duration of a realm = report, the reacting node only listens for updates to the realm report from= from the DOIC node that sent the realm report that resulted in the realm O= CS being stored. The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report. Steve ___________________________________________________________________________= ______________________________________________ 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_E8355113905631478EFF04F5AA706E9830A76516wtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I believe Nirav’s v= iew requires all hosts in a realm to be the same vendor and use a proprieta= ry communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are gener= ating the report, they must similarly be synchronized.

 <= /p>

Is seems like including t= he host name per Ulrich’s suggestion is a simple way of avoiding prop= rietary mechanisms or coupling between hosts and agents.<= /p>

In some applications, the= hosts can be completely decoupled (agnostic about each other). I think it = would be poor to add a synchronization requirement just to support DOIC.

 <= /p>

-Dave

 <= /p>

 <= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Friday, August 01, 2014 6:58 AM
To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Subject: Re: [Dime] DOIC issue #58 Proposal

 

Hi Steve,
 
I agree with Nirav's view. 
 
Regards,
 
Lionel 
 
Envoy=E9 depuis mon Sony Xperia SP d'Orange

 


---- Nirav Salot (nsalot) a =E9crit ----

 






Steve,<=
/p>

 <=
/p>

For this issue, I donR=
17;t agree to include identity of the DOIC node that sends the report, into=
 the realm reports.


 <=
/p>

In my view, the issue men=
tioned below – of two agents not 100% synchronize w.r.t the realm-rep=
ort – is the related to "how agents synchronized between themsel=
ves"
 and since that is not standardized we should not be developing protocol so=
lution for the case which occurs due to this out-of-standards solution.


 <=
/p>

Besides, I don’t se=
e any issue due to slight miss-synchronization of the realm-reports between=
 two agents since they should still represent the realm load more
 or less accurately. 


 <=
/p>

Also if the agents are no=
t synchronized and if they are playing the role of DOIC reacting node then =
they will apply abatement algorithm based on different values
 (for the same realm). So it does not matter if the client does the same.


 <=
/p>

Finally, I don’t se=
e any value-add of using the "identity of the node that sends the real=
m-report" to discard the other report related to the same realm. In
 other words, this same logic can be achieved using sequence-numbers as wel=
l, i.e. when the overload-report of an realm is active, the client is going=
 to ignore all the reports of the same realm which has lower sequence numbe=
r value. So in essence, when two
 agents are sending realm-reports, one of the reports is automatically igno=
red by the client if their sequence numbers differ. So the outcome without =
including the "identity if the node that sends realm report" is s=
ame as



>The effect should be that the reacting node will=
 accept a realm report from anyone when there is no active OLR for the real=
m but it will only listen to one reporting node when it has an active repor=
t.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Friday, August 01, 2014 1:23 AM

To: dime@ietf.org

Subject: [Dime] DOIC issue #58 Proposal






 


All,



Issue #58 deals with the fact that there can be multiple senders of realm o=
verload report for the same realm. 




Ulrich proposes one aspect of what is required in the issue description:


"In deployments where more than one node is configured to take the rol=
e of a reporting node for realm-routed-request reports, reacting nodes may =
receive in different answer messages different realm-routed-request type OL=
Rs inserted by the different reporting
 nodes. Although it is expected that the different reporting nodes report m=
ore or less the same content, it cannot be expected that reports are 100% s=
ynchronized. Especially sequence numbers may differ. To allow reacting node=
s correctly detect outdates/replays/freshness
 of OLRs in this scenario, it is proposed that realm-routed-request type OL=
Rs are extended to contain the Diameter Identity of the reporting node that=
 inserted the realm-routed-request type OLR. (e.g. as already proposed in
draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea=
lm-routed-request type OLRs to answer messages MUST also insert their Diame=
ter Identity. Reacting nodes MUST
 take the Diameter Identity received within the OLR into account in order t=
o detect outdates/replays/freshness. "



I agree with Ulrich that realm reports must include the identity of the DOI=
C node that sends the report.  This would be an optional AVP only requ=
ired for realm reports.  It would not be required for host reports as =
the identity of the sender of the host report
 is implicitly defined by the origin-host in the answer message.



I also agree that the Diameter Identity of the reporting node be used to de=
termine if a received report is ignored or used to update existing state.&n=
bsp; To this end I propose that we add wording that for the duration of a r=
ealm report, the reacting node only listens
 for updates to the realm report from from the DOIC node that sent the real=
m report that resulted in the realm OCS being stored.



The effect should be that the reacting node will accept a realm report from=
 anyone when there is no active OLR for the realm but it will only listen t=
o one reporting node when it has an active report.



Steve










______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.
--_000_E8355113905631478EFF04F5AA706E9830A76516wtlexchp2sandvi_-- From nobody Fri Aug 1 07:55:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31D11B27BA for ; Fri, 1 Aug 2014 07:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tODQlj1YX86f for ; Fri, 1 Aug 2014 07:55:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BF41B27BB for ; Fri, 1 Aug 2014 07:55:07 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s71Esw64091758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 09:55:00 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Fri, 1 Aug 2014 09:54:58 -0500 X-Mao-Original-Outgoing-Id: 428597698.242302-20176df20a355380261df7520be2d4d9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> To: Dave Dolson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9ax2UOiqfJAl_HKEeqlg3HAh668 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 14:55:11 -0000 +1 (modulo my comment to generalize) On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: > I believe Nirav=92s view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the = host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. > =20 > Is seems like including the host name per Ulrich=92s suggestion is a = simple way of avoiding proprietary mechanisms or coupling between hosts = and agents. > In some applications, the hosts can be completely decoupled (agnostic = about each other). I think it would be poor to add a synchronization = requirement just to support DOIC. > =20 > -Dave > =20 > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: Friday, August 01, 2014 6:58 AM > To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) > Subject: Re: [Dime] DOIC issue #58 Proposal > =20 > Hi Steve, > =20 > I agree with Nirav's view.=20 > =20 > Regards, > =20 > Lionel=20 > =20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange > =20 > ---- Nirav Salot (nsalot) a =E9crit ---- > =20 > Steve, > =20 > For this issue, I don=92t agree to include identity of the DOIC node = that sends the report, into the realm reports. > =20 > In my view, the issue mentioned below =96 of two agents not 100% = synchronize w.r.t the realm-report =96 is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. > =20 > Besides, I don=92t see any issue due to slight miss-synchronization of = the realm-reports between two agents since they should still represent = the realm load more or less accurately. > =20 > Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm = based on different values (for the same realm). So it does not matter if = the client does the same. > =20 > Finally, I don=92t see any value-add of using the "identity of the = node that sends the realm-report" to discard the other report related to = the same realm. In other words, this same logic can be achieved using = sequence-numbers as well, i.e. when the overload-report of an realm is = active, the client is going to ignore all the reports of the same realm = which has lower sequence number value. So in essence, when two agents = are sending realm-reports, one of the reports is automatically ignored = by the client if their sequence numbers differ. So the outcome without = including the "identity if the node that sends realm report" is same as > >The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Friday, August 01, 2014 1:23 AM > To: dime@ietf.org > Subject: [Dime] DOIC issue #58 Proposal > =20 > All, >=20 > Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. =20 >=20 > Ulrich proposes one aspect of what is required in the issue = description: >=20 > "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness. " >=20 > I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports = as the identity of the sender of the host report is implicitly defined = by the origin-host in the answer message. >=20 > I also agree that the Diameter Identity of the reporting node be used = to determine if a received report is ignored or used to update existing = state. To this end I propose that we add wording that for the duration = of a realm report, the reacting node only listens for updates to the = realm report from from the DOIC node that sent the realm report that = resulted in the realm OCS being stored. >=20 > The effect should be that the reacting node will accept a realm report = from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >=20 > Steve >=20 >=20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Aug 1 08:50:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8662B1B2793 for ; Fri, 1 Aug 2014 08:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3sAcPK67U2g for ; Fri, 1 Aug 2014 08:50:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9541B2791 for ; Fri, 1 Aug 2014 08:50:25 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C86D72ACFBA; Fri, 1 Aug 2014 17:50:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id AC5D0C804F; Fri, 1 Aug 2014 17:50:22 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 17:50:16 +0200 From: To: Ben Campbell , Jouni Korhonen Thread-Topic: [Dime] DOIC: Base protocol vs application Thread-Index: AQHPrDOf5TplgyrNLU28W6D8dfz75Zu5oRsAgAB1IACAACIZsP//7e+AgAAiDZCAACKKAIAAKuuAgAABugCAAIPVAIAAjt6AgAAtz2A= Date: Fri, 1 Aug 2014 15:50:15 +0000 Message-ID: <18570_1406908222_53DBB73E_18570_9276_1_6B7134B31289DC4FAF731D844122B36E687D1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> <53DAB779.5000303@gmail.com> <5EFE4D16-4C2E-4583-8D40-5C70F9FE1FE7@nostrum.com> <53DB2782.4080909@gmail.com> <562909D4-B02B-4856-9B4A-90648DC1B8D3@nostrum.com> In-Reply-To: <562909D4-B02B-4856-9B4A-90648DC1B8D3@nostrum.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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.140020 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JUBX_-eHV_0AkCquM-2jGqSlNuo Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 15:50:27 -0000 Hi Ben, The initial point was not only about inserting OLR in answers, it was also = about using "the received load and overload information to support graceful= behavior during an overload condition." I think that inserting OLR AVP and performing overload abatement actions on= behalf of a non-DOICable node require maintaining an overload control stat= e for each associated non-DOIC node. As I said earlier, it would mean also = that this node knows how to perform such abatement, which is defined at the= application layer. This is why such actions cannot be performed by a simple Relay but only by = a proxy. Now, I want to make clear the distinction between the role of Relay agent a= s defined in the RFC6733 and the functions assigned to a Diameter node curr= ently deployed in the networks for request/answer forwarding. If the former= is pretty restrictive in terms of functionalities performed by the agent a= cting as Relay, there is no such restriction regarding the latter. But this= is implementation specific and outside the standardization scope. I still don't see why a forwarding proxy advertising all the applications f= or which DOIC is supported is not enough to cover your concern. In any case= , assuming that "pure" Relay agents would have been deployed in the network= , they will have to be upgraded to support DOIC. Along this upgrade, I don'= t see any issue to modify its role from "Relay" to "Proxy" and add the supp= orted appli-Id in the CER/CEA. Regards, Lionel =20 -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: vendredi 1 ao=FBt 2014 16:08 =C0=A0: Jouni Korhonen Cc=A0: MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: Re: [Dime] DOIC: Base protocol vs application On Aug 1, 2014, at 12:37 AM, Jouni Korhonen wrote: >>>=20 >>> A "node" as a DOICable relay can do DOIC stuff to _any_ application wit= hin certain limits. If the "DOIC stuff" is just applying the abatement, the= n that is OK for _any_ application depending on the abatement algorithm. If= the "DOIC stuff" is beyond that e.g. adding/removing DOIC AVPs then the DO= ICable relay has to be application aware _internally_ i.e. a proxy.. otherw= ise it might e.g. cause trouble with applications whose messages' CCF has n= o *[AVP]. >>=20 >> Adam did a survey way back when, and found that such applications are va= nishingly rare. (Was it just the watchdog application?). Hopefully people w= on't try to define new applications without *[AVP]/ >=20 > I know. *[AVP] was just an example. Another example would be new applicat= ions that embed DOIC as a part of their formal CCF and there even changing = the location of the DOIC AVP could break the CCF check. We could offer guidance to not make the DOIC AVPs fixed. OTOH, I see there might be some issues with interfering with other fixed po= sition AVPs in the CCF, if an relay that doesn't know the CCF changes their= position by inserting DOIC AVPs. We could recommend such relays insert at= the end, but there are probably efficiency reasons to add them close to th= e front. I guess we could say "add close to the top if you understand the C= CF, otherwise add at the end." To be clear, I think the most common use of DOIC at agents would be at prox= ies, so this becomes an edge case. It's just an edge case I think we need t= o support. ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 08:58:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFCF1B2791 for ; Fri, 1 Aug 2014 08:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF67OngE8DJs for ; Fri, 1 Aug 2014 08:58:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341EF1A0B0C for ; Fri, 1 Aug 2014 08:58:26 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 189E7324D49; Fri, 1 Aug 2014 17:58:24 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A834827C06A; Fri, 1 Aug 2014 17:58:22 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 17:58:22 +0200 From: To: Dave Dolson , Steve Donovan , "dime@ietf.org" , "Nirav Salot (nsalot)" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrPkUKkwluafl4k6XkejzZpuF5Zu7GrAAgAB6ZfiAAB8dAIAAMtHw Date: Fri, 1 Aug 2014 15:58:21 +0000 Message-ID: <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.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: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E687DBEPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.140020 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/X4ljffcCCllBes5XW5YGIwd5fLI Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 15:58:32 -0000 --_000_6B7134B31289DC4FAF731D844122B36E687DBEPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, The whole purpose of "Realm" report is to provide a consolidated view of th= e overload status of all the servers in the realm. If you are not able to provide such consolidated view for the entire realm,= you will not be able to send OLR with the type "Realm". The synchronization between nodes might not be required but it is required = that all the agents providing Realm-based OLR have the means to provide a "= common" view, whatever the mechanism used for that. Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 1 ao=FBt 2014 16:50 =C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nirav Salot (nsa= lot) Objet : RE: [Dime] DOIC issue #58 Proposal I believe Nirav's view requires all hosts in a realm to be the same vendor = and use a proprietary communication protocol to synchronize the host report= . Or, if a multiple (redundant or active-active) load-balancing agents are = generating the report, they must similarly be synchronized. Is seems like including the host name per Ulrich's suggestion is a simple w= ay of avoiding proprietary mechanisms or coupling between hosts and agents. In some applications, the hosts can be completely decoupled (agnostic about= each other). I think it would be poor to add a synchronization requirement= just to support DOIC. -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Friday, August 01, 2014 6:58 AM To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree with Nirav's view. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. In my view, the issue mentioned below - of two agents not 100% synchronize = w.r.t the realm-report - is the related to "how agents synchronized between= themselves" and since that is not standardized we should not be developing= protocol solution for the case which occurs due to this out-of-standards s= olution. Besides, I don't see any issue due to slight miss-synchronization of the re= alm-reports between two agents since they should still represent the realm = load more or less accurately. Also if the agents are not synchronized and if they are playing the role of= DOIC reacting node then they will apply abatement algorithm based on diffe= rent values (for the same realm). So it does not matter if the client does = the same. Finally, I don't see any value-add of using the "identity of the node that = sends the realm-report" to discard the other report related to the same rea= lm. In other words, this same logic can be achieved using sequence-numbers = as well, i.e. when the overload-report of an realm is active, the client is= going to ignore all the reports of the same realm which has lower sequence= number value. So in essence, when two agents are sending realm-reports, on= e of the reports is automatically ignored by the client if their sequence n= umbers differ. So the outcome without including the "identity if the node t= hat sends realm report" is same as >The effect should be that the reacting node will accept a realm report fro= m anyone when there is no active OLR for the realm but it will only listen = to one reporting node when it has an active report. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 1:23 AM To: dime@ietf.org Subject: [Dime] DOIC issue #58 Proposal All, Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of = a reporting node for realm-routed-request reports, reacting nodes may recei= ve in different answer messages different realm-routed-request type OLRs in= serted by the different reporting nodes. Although it is expected that the d= ifferent reporting nodes report more or less the same content, it cannot be= expected that reports are 100% synchronized. Especially sequence numbers m= ay differ. To allow reacting nodes correctly detect outdates/replays/freshn= ess of OLRs in this scenario, it is proposed that realm-routed-request type= OLRs are extended to contain the Diameter Identity of the reporting node t= hat inserted the realm-routed-request type OLR. (e.g. as already proposed i= n draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-req= uest type OLRs to answer messages MUST also insert their Diameter Identity.= Reacting nodes MUST take the Diameter Identity received within the OLR int= o account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report. This would be an optional AVP only required = for realm reports. It would not be required for host reports as the identi= ty of the sender of the host report is implicitly defined by the origin-hos= t in the answer message. I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state. = To this end I propose that we add wording that for the duration of a realm = report, the reacting node only listens for updates to the realm report from= from the DOIC node that sent the realm report that resulted in the realm O= CS being stored. The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report. Steve ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E687DBEPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 = ;

The whole = purpose of "Realm" report is to provide a consolidated view of th= e overload status of all the servers in the realm.

If you are= not able to provide such consolidated view for the entire realm, you will = not be able to send OLR with the type "Realm".<= /p>

The synchr= onization between nodes might not be required but it is required that all t= he agents providing Realm-based OLR have the means to provide a "common" view, whatever the mechanism used for that.

 = ;

Lionel

 = ;

 = ;

De := Dave Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 1 ao=FBt 2014 16:50
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nira= v Salot (nsalot)
Objet : RE: [Dime] DOIC issue #58 Proposal

 

I believe = Nirav’s view requires all hosts in a realm to be the same vendor and = use a proprietary communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agen= ts are generating the report, they must similarly be synchronized.

 = ;

Is seems l= ike including the host name per Ulrich’s suggestion is a simple way o= f avoiding proprietary mechanisms or coupling between hosts and agents.

In some ap= plications, the hosts can be completely decoupled (agnostic about each othe= r). I think it would be poor to add a synchronization requirement just to support DOIC.

 = ;

-Dave=

 = ;

 = ;

 = ;

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Friday, August 01, 2014 6:58 AM
To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Subject: Re: [Dime] DOIC issue #58 Proposal

 

Hi Steve,
 
I agree with Nirav's view. 

 


Regards,


 


Lionel 


 


Envoy=E9 depuis mon Sony Xperia SP d'Orange=



 


---- Nirav Salot (nsalot) a =E9crit ----


 






Steve,


 


For this i=
ssue, I don’t agree to include identity of the DOIC node that sends t=
he report, into the realm reports.


 


In my view=
, the issue mentioned below – of two agents not 100% synchronize w.r.=
t the realm-report – is the related to "how agents synchronized
 between themselves" and since that is not standardized we should not =
be developing protocol solution for the case which occurs due to this out-o=
f-standards solution.


 


Besides, I=
 don’t see any issue due to slight miss-synchronization of the realm-=
reports between two agents since they should still represent the
 realm load more or less accurately. 


 


Also if th=
e agents are not synchronized and if they are playing the role of DOIC reac=
ting node then they will apply abatement algorithm based on
 different values (for the same realm). So it does not matter if the client=
 does the same.


 


Finally, I=
 don’t see any value-add of using the "identity of the node that=
 sends the realm-report" to discard the other report related to the sa=
me
 realm. In other words, this same logic can be achieved using sequence-numb=
ers as well, i.e. when the overload-report of an realm is active, the clien=
t is going to ignore all the reports of the same realm which has lower sequ=
ence number value. So in essence,
 when two agents are sending realm-reports, one of the reports is automatic=
ally ignored by the client if their sequence numbers differ. So the outcome=
 without including the "identity if the node that sends realm report&q=
uot; is same as



>The effect should be that t=
he reacting node will accept a realm report from anyone when there is no ac=
tive OLR for the realm but it will only listen to one reporting node when i=
t has an active report.


 


Regards,


Nirav.


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Friday, August 01, 2014 1:23 AM

To: dime@ietf.org

Subject: [Dime] DOIC issue #58 Proposal<=
o:p>






 


=
All,



Issue #58 deals with the fact that there can be multiple senders of realm o=
verload report for the same realm. 




Ulrich proposes one aspect of what is required in the issue description:



"In deployments where more than one node is configured to take the rol=
e of a reporting node for realm-routed-request reports, reacting nodes may =
receive in different answer messages different realm-routed-request type OL=
Rs inserted by the different reporting
 nodes. Although it is expected that the different reporting nodes report m=
ore or less the same content, it cannot be expected that reports are 100% s=
ynchronized. Especially sequence numbers may differ. To allow reacting node=
s correctly detect outdates/replays/freshness
 of OLRs in this scenario, it is proposed that realm-routed-request type OL=
Rs are extended to contain the Diameter Identity of the reporting node that=
 inserted the realm-routed-request type OLR. (e.g. as already proposed in
draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea=
lm-routed-request type OLRs to answer messages MUST also insert their Diame=
ter Identity. Reacting nodes MUST
 take the Diameter Identity received within the OLR into account in order t=
o detect outdates/replays/freshness. "



I agree with Ulrich that realm reports must include the identity of the DOI=
C node that sends the report.  This would be an optional AVP only requ=
ired for realm reports.  It would not be required for host reports as =
the identity of the sender of the host report
 is implicitly defined by the origin-host in the answer message.



I also agree that the Diameter Identity of the reporting node be used to de=
termine if a received report is ignored or used to update existing state.&n=
bsp; To this end I propose that we add wording that for the duration of a r=
ealm report, the reacting node only listens
 for updates to the realm report from from the DOIC node that sent the real=
m report that resulted in the realm OCS being stored.



The effect should be that the reacting node will accept a realm report from=
 anyone when there is no active OLR for the realm but it will only listen t=
o one reporting node when it has an active report.



Steve






_________________________________________________=
________________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=



Thank you.


______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E687DBEPEXCVZYM13corpora_-- From nobody Fri Aug 1 09:04:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49ED1B27EB for ; Fri, 1 Aug 2014 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mek4izrt009a for ; Fri, 1 Aug 2014 09:04:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE3D1A0B0C for ; Fri, 1 Aug 2014 09:04:24 -0700 (PDT) Received: from localhost ([::1]:38715 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XDFJW-0000e2-Aj; Fri, 01 Aug 2014 09:04:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Fri, 01 Aug 2014 16:04:14 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/48#comment:2 Message-ID: <072.13bb002f77067e196c222361d3b94e84@trac.tools.ietf.org> References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AefBQLAizEfhJBJK2oDjnImJCcM Cc: dime@ietf.org Subject: Re: [Dime] [dime] #48 (draft-ietf-dime-ovli): Setting M-Bit gives wrong semantics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:04:28 -0000 #48: Setting M-Bit gives wrong semantics Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => invalid Comment: Consensus was reached that no changes are required. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: invalid Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Fri Aug 1 09:09:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACE51B27ED for ; Fri, 1 Aug 2014 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBhY1S4kP47t for ; Fri, 1 Aug 2014 09:09:32 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB1A1B27EB for ; Fri, 1 Aug 2014 09:09:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49459 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDFOc-0000h6-8K for dime@ietf.org; Fri, 01 Aug 2014 09:09:31 -0700 Message-ID: <53DBBBBA.3060200@usdonovans.com> Date: Fri, 01 Aug 2014 11:09:30 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-OutGoing-Spam-Status: No, score=-1.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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6SZt5oUDhGdRsdkoGzqUt03Sg2I Subject: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 16:09:34 -0000 Somewhat on on the path toward generalization, we have a second issue=20 currently open that can be solved by having the DOIC node that inserts=20 an overload report in an answer message include it's own diameter=20 identity in the overload report. I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Host= =2E This issue points out that existing non DOIC agents are able to change=20 the origin-host in answer messages. One example of where this is done=20 is in topology hiding implementations. This issue can be addressed through attribution of overload reports. As such, I propose that we add a required AVP to the OC-OLR group AVP=20 that carries the diameter identity of the DOIC node that inserted the=20 overload report into the answer message. Issue #66 points out the need=20 in host reports and issue #58 points out the need in realm reports. Steve On 8/1/14, 9:54 AM, Ben Campbell wrote: > +1 (modulo my comment to generalize) > > On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: > >> I believe Nirav=92s view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the ho= st report. Or, if a multiple (redundant or active-active) load-balancing = agents are generating the report, they must similarly be synchronized. >> =20 >> Is seems like including the host name per Ulrich=92s suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >> In some applications, the hosts can be completely decoupled (agnostic = about each other). I think it would be poor to add a synchronization requ= irement just to support DOIC. >> =20 >> -Dave >> =20 >> =20 >> =20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@o= range.com >> Sent: Friday, August 01, 2014 6:58 AM >> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >> Subject: Re: [Dime] DOIC issue #58 Proposal >> =20 >> Hi Steve, >> =20 >> I agree with Nirav's view. >> =20 >> Regards, >> =20 >> Lionel >> =20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> =20 >> ---- Nirav Salot (nsalot) a =E9crit ---- >> =20 >> Steve, >> =20 >> For this issue, I don=92t agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >> =20 >> In my view, the issue mentioned below =96 of two agents not 100% synch= ronize w.r.t the realm-report =96 is the related to "how agents synchroni= zed between themselves" and since that is not standardized we should not = be developing protocol solution for the case which occurs due to this out= -of-standards solution. >> =20 >> Besides, I don=92t see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >> =20 >> Also if the agents are not synchronized and if they are playing the ro= le of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the cli= ent does the same. >> =20 >> Finally, I don=92t see any value-add of using the "identity of the nod= e that sends the realm-report" to discard the other report related to the= same realm. In other words, this same logic can be achieved using sequen= ce-numbers as well, i.e. when the overload-report of an realm is active, = the client is going to ignore all the reports of the same realm which has= lower sequence number value. So in essence, when two agents are sending = realm-reports, one of the reports is automatically ignored by the client = if their sequence numbers differ. So the outcome without including the "i= dentity if the node that sends realm report" is same as >>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >> =20 >> Regards, >> Nirav. >> =20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Friday, August 01, 2014 1:23 AM >> To: dime@ietf.org >> Subject: [Dime] DOIC issue #58 Proposal >> =20 >> All, >> >> Issue #58 deals with the fact that there can be multiple senders of re= alm overload report for the same realm. >> >> Ulrich proposes one aspect of what is required in the issue descriptio= n: >> >> "In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes ma= y receive in different answer messages different realm-routed-request typ= e OLRs inserted by the different reporting nodes. Although it is expected= that the different reporting nodes report more or less the same content,= it cannot be expected that reports are 100% synchronized. Especially seq= uence numbers may differ. To allow reacting nodes correctly detect outdat= es/replays/freshness of OLRs in this scenario, it is proposed that realm-= routed-request type OLRs are extended to contain the Diameter Identity of= the reporting node that inserted the realm-routed-request type OLR. (e.g= =2E as already proposed in draft-donovan-dime-agent-overload-01). Reporti= ng nodes that insert realm-routed-request type OLRs to answer messages MU= ST also insert their Diameter Identity. Reacting nodes MUST take the Diam= eter Identity received within the OLR into account in order to detect out= dates/replays/freshness." >> >> I agree with Ulrich that realm reports must include the identity of th= e DOIC node that sends the report. This would be an optional AVP only re= quired for realm reports. It would not be required for host reports as t= he identity of the sender of the host report is implicitly defined by the= origin-host in the answer message. >> >> I also agree that the Diameter Identity of the reporting node be used = to determine if a received report is ignored or used to update existing s= tate. To this end I propose that we add wording that for the duration of= a realm report, the reacting node only listens for updates to the realm = report from from the DOIC node that sent the realm report that resulted i= n the realm OCS being stored. >> >> The effect should be that the reacting node will accept a realm report= from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >> >> Steve >> >> >> ______________________________________________________________________= ___________________________________________________ >> =20 >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> =20 >> This message and its attachments may contain confidential or privilege= d 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. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Aug 1 09:13:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18D11B27ED for ; Fri, 1 Aug 2014 09:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcVVkTIKJdT2 for ; Fri, 1 Aug 2014 09:12:55 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756D81B27F2 for ; Fri, 1 Aug 2014 09:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39576; q=dns/txt; s=iport; t=1406909575; x=1408119175; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Tl1G7D9Wmvpnf1YwR8ZuNMXKsUMps4nTr820eBz8X4Q=; b=Y2NVYHeIENAoAzCZg9KS1MgtkjIprouo3XpR+uPGsk9i2E2go7KLV3Nn Gvp4iJCGCDdNdQwf68k4AvrtRKJtEsCzwf2tAl+zYieZOwgjY3uKX5SUx QfrKYWaMoWMPQCbjHwY5i/PnMISBqptbHEX9b+jqebPSv57m3rTW3Y1ky I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAKm721OtJA2I/2dsb2JhbABSCYJHRlJXBMoqgWKHTAGBCxZ3hAMBAQEDAS1RCwIBCBEEAQELCwsBBgcyFAkIAgQBEggTiB8IDcoHF45qBwoBHzcBBgSDJYEcBYpOhCCIYYV/kwaDSWyBAwcCFyI X-IronPort-AV: E=Sophos; i="5.01,780,1400025600"; d="scan'208,217"; a="65824900" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 01 Aug 2014 16:12:53 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s71GCrMB009731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 16:12:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 11:12:53 -0500 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , Dave Dolson , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrPj5lwrN9479MEmgKHB41eF0/5u7N7ZAgACxMQCAAECkAIAAEyqA//+uAIA= Date: Fri, 1 Aug 2014 16:12:53 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.140] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA018DDD842xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/H1GVANeQJWF0UaXmeSlsZ4tYN8E Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 16:13:01 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA018DDD842xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, On top of what Lionel mentioned, if you look at issue #58, we are already a= ssuming that agents providing report for the same realm are almost synchron= ized. > Although it is expected that the different reporting nodes report more or= less the same content, it cannot be expected that reports are 100% synchro= nized. Especially sequence numbers may differ. The issue we are solving is when there is slight miss-synchronization betwe= en those agents - for whatever reason - how does the client handle it. > To allow reacting nodes correctly detect outdates/replays/freshness of OL= Rs in this scenario, it is proposed that realm-routed-request type OLRs are= extended to contain the Diameter Identity of the reporting node that inser= ted the realm-routed-request type OLR. And that's where we are proposing to use "identity of agent providing realm= report". The client receives same report with two different identities (fr= om two different agents) and discard one of them. > Reacting nodes MUST take the Diameter Identity received within the OLR in= to account in order to detect outdates/replays/freshness. My main point was that, the same logic - of discarding report from one of t= he agent - can be achieved by using sequence number, which is already provi= ded as part of overload report. So in summary, there is no value in adding "Diameter identity of the agent = providing realm-report" for issue #58. Just to clarify, I am not assuming same vendor providing the agents. And, I= guess, that is not relevant to issue #58. Regards, Nirav. From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Friday, August 01, 2014 9:28 PM To: Dave Dolson; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) Subject: RE: [Dime] DOIC issue #58 Proposal Hi Dave, The whole purpose of "Realm" report is to provide a consolidated view of th= e overload status of all the servers in the realm. If you are not able to provide such consolidated view for the entire realm,= you will not be able to send OLR with the type "Realm". The synchronization between nodes might not be required but it is required = that all the agents providing Realm-based OLR have the means to provide a "= common" view, whatever the mechanism used for that. Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 1 ao=FBt 2014 16:50 =C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) Objet : RE: [Dime] DOIC issue #58 Proposal I believe Nirav's view requires all hosts in a realm to be the same vendor = and use a proprietary communication protocol to synchronize the host report= . Or, if a multiple (redundant or active-active) load-balancing agents are = generating the report, they must similarly be synchronized. Is seems like including the host name per Ulrich's suggestion is a simple w= ay of avoiding proprietary mechanisms or coupling between hosts and agents. In some applications, the hosts can be completely decoupled (agnostic about= each other). I think it would be poor to add a synchronization requirement= just to support DOIC. -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Friday, August 01, 2014 6:58 AM To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot= ) Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree with Nirav's view. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. In my view, the issue mentioned below - of two agents not 100% synchronize = w.r.t the realm-report - is the related to "how agents synchronized between= themselves" and since that is not standardized we should not be developing= protocol solution for the case which occurs due to this out-of-standards s= olution. Besides, I don't see any issue due to slight miss-synchronization of the re= alm-reports between two agents since they should still represent the realm = load more or less accurately. Also if the agents are not synchronized and if they are playing the role of= DOIC reacting node then they will apply abatement algorithm based on diffe= rent values (for the same realm). So it does not matter if the client does = the same. Finally, I don't see any value-add of using the "identity of the node that = sends the realm-report" to discard the other report related to the same rea= lm. In other words, this same logic can be achieved using sequence-numbers = as well, i.e. when the overload-report of an realm is active, the client is= going to ignore all the reports of the same realm which has lower sequence= number value. So in essence, when two agents are sending realm-reports, on= e of the reports is automatically ignored by the client if their sequence n= umbers differ. So the outcome without including the "identity if the node t= hat sends realm report" is same as >The effect should be that the reacting node will accept a realm report fro= m anyone when there is no active OLR for the realm but it will only listen = to one reporting node when it has an active report. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 1:23 AM To: dime@ietf.org Subject: [Dime] DOIC issue #58 Proposal All, Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of = a reporting node for realm-routed-request reports, reacting nodes may recei= ve in different answer messages different realm-routed-request type OLRs in= serted by the different reporting nodes. Although it is expected that the d= ifferent reporting nodes report more or less the same content, it cannot be= expected that reports are 100% synchronized. Especially sequence numbers m= ay differ. To allow reacting nodes correctly detect outdates/replays/freshn= ess of OLRs in this scenario, it is proposed that realm-routed-request type= OLRs are extended to contain the Diameter Identity of the reporting node t= hat inserted the realm-routed-request type OLR. (e.g. as already proposed i= n draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-req= uest type OLRs to answer messages MUST also insert their Diameter Identity.= Reacting nodes MUST take the Diameter Identity received within the OLR int= o account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report. This would be an optional AVP only required = for realm reports. It would not be required for host reports as the identi= ty of the sender of the host report is implicitly defined by the origin-hos= t in the answer message. I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state. = To this end I propose that we add wording that for the duration of a realm = report, the reacting node only listens for updates to the realm report from= from the DOIC node that sent the realm report that resulted in the realm O= CS being stored. The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report. Steve ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_A9CA33BB78081F478946E4F34BF9AAA018DDD842xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 <= /p>

On top of what Lionel men= tioned, if you look at issue #58, we are already assuming that agents provi= ding report for the same realm are almost synchronized.

> Although it i= s expected that the different reporting nodes report more or less the same = content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ.

The issue we are solving = is when there is slight miss-synchronization between those agents – f= or whatever reason – how does the client handle it.=

> To allow reac= ting nodes correctly detect outdates/replays/freshness of OLRs in this scen= ario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inser= ted the realm-routed-request type OLR.

 <= /p>

And that’s where we= are proposing to use "identity of agent providing realm report".= The client receives same report with two different identities (from two different agents) and discard one of them.

> Reacting node= s MUST take the Diameter Identity received within the OLR into account in o= rder to detect outdates/replays/freshness.<= /o:p>

My main point was that, t= he same logic – of discarding report from one of the agent – ca= n be achieved by using sequence number, which is already provided as part of overload report.

So in summary, there is n= o value in adding "Diameter identity of the agent providing realm-repo= rt" for issue #58.

 <= /p>

Just to clarify, I am not= assuming same vendor providing the agents. And, I guess, that is not relev= ant to issue #58.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: lionel.morand@orange.com [mailto:lionel.morand@or= ange.com]
Sent: Friday, August 01, 2014 9:28 PM
To: Dave Dolson; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)<= br> Subject: RE: [Dime] DOIC issue #58 Proposal

 

Hi Dave,

 <= /p>

The whole purpose of &quo= t;Realm" report is to provide a consolidated view of the overload stat= us of all the servers in the realm.

If you are not able to pr= ovide such consolidated view for the entire realm, you will not be able to = send OLR with the type "Realm".

The synchronization betwe= en nodes might not be required but it is required that all the agents provi= ding Realm-based OLR have the means to provide a "common" view, whatever the mechanism used for that.

 <= /p>

Lionel<= /p>

 <= /p>

 <= /p>

De = : Dave Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 1 ao=FBt 2014 16:50
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Objet : RE: [Dime] DOIC issue #58 Proposal

 

I believe Nirav’s v= iew requires all hosts in a realm to be the same vendor and use a proprieta= ry communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are gener= ating the report, they must similarly be synchronized.

 <= /p>

Is seems like including t= he host name per Ulrich’s suggestion is a simple way of avoiding prop= rietary mechanisms or coupling between hosts and agents.<= /p>

In some applications, the= hosts can be completely decoupled (agnostic about each other). I think it = would be poor to add a synchronization requirement just to support DOIC.

 <= /p>

-Dave

 <= /p>

 <= /p>

 <= /p>

 

Hi Steve,
 
I agree with Nirav's view. 
 
Regards,
 
Lionel 
 
Envoy=E9 depuis mon Sony Xperia SP d'Orange
 
---- Nirav Salot (nsalot) a =E9crit ----=

 

Steve,<= /p>

 <= /p>

For this issue, I donR= 17;t agree to include identity of the DOIC node that sends the report, into= the realm reports.

 <= /p>

In my view, the issue men= tioned below – of two agents not 100% synchronize w.r.t the realm-rep= ort – is the related to "how agents synchronized between themsel= ves" and since that is not standardized we should not be developing protocol so= lution for the case which occurs due to this out-of-standards solution.

 <= /p>

Besides, I don’t se= e any issue due to slight miss-synchronization of the realm-reports between= two agents since they should still represent the realm load more or less accurately.

 <= /p>

Also if the agents are no= t synchronized and if they are playing the role of DOIC reacting node then = they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same.

 <= /p>

Finally, I don’t se= e any value-add of using the "identity of the node that sends the real= m-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as wel= l, i.e. when the overload-report of an realm is active, the client is going= to ignore all the reports of the same realm which has lower sequence numbe= r value. So in essence, when two agents are sending realm-reports, one of the reports is automatically igno= red by the client if their sequence numbers differ. So the outcome without = including the "identity if the node that sends realm report" is s= ame as

>The effect should be that the reacting node will= accept a realm report from anyone when there is no active OLR for the real= m but it will only listen to one reporting node when it has an active repor= t.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: dime@ietf.org
Subject: [Dime] DOIC issue #58 Proposal

 

All,

Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. 

Ulrich proposes one aspect of what is required in the issue description:
"In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report m= ore or less the same content, it cannot be expected that reports are 100% s= ynchronized. Especially sequence numbers may differ. To allow reacting node= s correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OL= Rs are extended to contain the Diameter Identity of the reporting node that= inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea= lm-routed-request type OLRs to answer messages MUST also insert their Diame= ter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order t= o detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report.  This would be an optional AVP only requ= ired for realm reports.  It would not be required for host reports as = the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state.&n= bsp; To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the real= m report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report.

Steve

___________________________________________________________=
______________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des infor=
mations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. S=
i 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 alt=
ere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential o=
r privileged information that may be protected by law;

they should not be distributed, used or copied without auth=
orisation.


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.


_______________________________________________=
__________________________________________________________________________<=
o:p>


 


Ce message et ses pieces jointes peuvent conten=
ir des informations confidentielles ou privilegiees et ne doivent donc=



pas etre diffuses, exploites ou copies sans aut=
orisation. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pie=
ces jointes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce messa=
ge a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain co=
nfidential 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, pleas=
e 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.
--_000_A9CA33BB78081F478946E4F34BF9AAA018DDD842xmbrcdx10ciscoc_-- From nobody Fri Aug 1 09:16:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B277A1B27F2 for ; Fri, 1 Aug 2014 09:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgr1Gnrkjj1y for ; Fri, 1 Aug 2014 09:16:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8478A1B27F9 for ; Fri, 1 Aug 2014 09:16:30 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C80D618CBFF; Fri, 1 Aug 2014 18:16:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A9FEE4C066; Fri, 1 Aug 2014 18:16:28 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 18:16:28 +0200 From: To: Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u768Zg Date: Fri, 1 Aug 2014 16:16:26 +0000 Message-ID: <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> In-Reply-To: <53DBBBBA.3060200@usdonovans.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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.140020 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x5djxfq7b9rC7GC_B7EpqpX30qY Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 16:16:33 -0000 Hi Steve, Not sure to understand. If an agent inserts its identity as Origin-host in = answers forwarded from servers, the client will see the agent as the server. What will be the added-value to add the identity of the server inserting th= e OLR if the client will store this information along the agent id? Sorry if I've missed something... Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: vendredi 1 ao=FBt 2014 18:10 Cc=A0: dime@ietf.org Objet=A0: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Pr= oposal) Somewhat on on the path toward generalization, we have a second issue=20 currently open that can be solved by having the DOIC node that inserts=20 an overload report in an answer message include it's own diameter=20 identity in the overload report. I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Host. This issue points out that existing non DOIC agents are able to change=20 the origin-host in answer messages. One example of where this is done=20 is in topology hiding implementations. This issue can be addressed through attribution of overload reports. As such, I propose that we add a required AVP to the OC-OLR group AVP=20 that carries the diameter identity of the DOIC node that inserted the=20 overload report into the answer message. Issue #66 points out the need=20 in host reports and issue #58 points out the need in realm reports. Steve On 8/1/14, 9:54 AM, Ben Campbell wrote: > +1 (modulo my comment to generalize) > > On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: > >> I believe Nirav's view requires all hosts in a realm to be the same vend= or and use a proprietary communication protocol to synchronize the host rep= ort. Or, if a multiple (redundant or active-active) load-balancing agents a= re generating the report, they must similarly be synchronized. >>=20=20=20 >> Is seems like including the host name per Ulrich's suggestion is a simpl= e way of avoiding proprietary mechanisms or coupling between hosts and agen= ts. >> In some applications, the hosts can be completely decoupled (agnostic ab= out each other). I think it would be poor to add a synchronization requirem= ent just to support DOIC. >>=20=20=20 >> -Dave >>=20=20=20 >>=20=20=20 >>=20=20=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@ora= nge.com >> Sent: Friday, August 01, 2014 6:58 AM >> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >> Subject: Re: [Dime] DOIC issue #58 Proposal >>=20=20=20 >> Hi Steve, >>=20=20=20 >> I agree with Nirav's view. >>=20=20=20 >> Regards, >>=20=20=20 >> Lionel >>=20=20=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20=20=20 >> ---- Nirav Salot (nsalot) a =E9crit ---- >>=20=20=20 >> Steve, >>=20=20=20 >> For this issue, I don't agree to include identity of the DOIC node that = sends the report, into the realm reports. >>=20=20=20 >> In my view, the issue mentioned below - of two agents not 100% synchroni= ze w.r.t the realm-report - is the related to "how agents synchronized betw= een themselves" and since that is not standardized we should not be develop= ing protocol solution for the case which occurs due to this out-of-standard= s solution. >>=20=20=20 >> Besides, I don't see any issue due to slight miss-synchronization of the= realm-reports between two agents since they should still represent the rea= lm load more or less accurately. >>=20=20=20 >> Also if the agents are not synchronized and if they are playing the role= of DOIC reacting node then they will apply abatement algorithm based on di= fferent values (for the same realm). So it does not matter if the client do= es the same. >>=20=20=20 >> Finally, I don't see any value-add of using the "identity of the node th= at sends the realm-report" to discard the other report related to the same = realm. In other words, this same logic can be achieved using sequence-numbe= rs as well, i.e. when the overload-report of an realm is active, the client= is going to ignore all the reports of the same realm which has lower seque= nce number value. So in essence, when two agents are sending realm-reports,= one of the reports is automatically ignored by the client if their sequenc= e numbers differ. So the outcome without including the "identity if the nod= e that sends realm report" is same as >>> The effect should be that the reacting node will accept a realm report = from anyone when there is no active OLR for the realm but it will only list= en to one reporting node when it has an active report. >>=20=20=20 >> Regards, >> Nirav. >>=20=20=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Friday, August 01, 2014 1:23 AM >> To: dime@ietf.org >> Subject: [Dime] DOIC issue #58 Proposal >>=20=20=20 >> All, >> >> Issue #58 deals with the fact that there can be multiple senders of real= m overload report for the same realm. >> >> Ulrich proposes one aspect of what is required in the issue description: >> >> "In deployments where more than one node is configured to take the role = of a reporting node for realm-routed-request reports, reacting nodes may re= ceive in different answer messages different realm-routed-request type OLRs= inserted by the different reporting nodes. Although it is expected that th= e different reporting nodes report more or less the same content, it cannot= be expected that reports are 100% synchronized. Especially sequence number= s may differ. To allow reacting nodes correctly detect outdates/replays/fre= shness of OLRs in this scenario, it is proposed that realm-routed-request t= ype OLRs are extended to contain the Diameter Identity of the reporting nod= e that inserted the realm-routed-request type OLR. (e.g. as already propose= d in draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea= lm-routed-request type OLRs to answer messages MUST also insert their Diame= ter Identity. Reacting nodes MUST take the Diameter Identity received withi= n the OLR into account in order to detect outdates/replays/freshness." >> >> I agree with Ulrich that realm reports must include the identity of the = DOIC node that sends the report. This would be an optional AVP only requir= ed for realm reports. It would not be required for host reports as the ide= ntity of the sender of the host report is implicitly defined by the origin-= host in the answer message. >> >> I also agree that the Diameter Identity of the reporting node be used to= determine if a received report is ignored or used to update existing state= . To this end I propose that we add wording that for the duration of a rea= lm report, the reacting node only listens for updates to the realm report f= rom from the DOIC node that sent the realm report that resulted in the real= m OCS being stored. >> >> The effect should be that the reacting node will accept a realm report f= rom anyone when there is no active OLR for the realm but it will only liste= n to one reporting node when it has an active report. >> >> Steve >> >> >> ________________________________________________________________________= _________________________________________________ >>=20=20=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20=20=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 10:49:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1701A028A for ; Fri, 1 Aug 2014 10:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7wjlHTjVQwz for ; Fri, 1 Aug 2014 10:49:05 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53981B2883 for ; Fri, 1 Aug 2014 10:49:04 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49694 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDGwr-0007SK-7e; Fri, 01 Aug 2014 10:49:03 -0700 Message-ID: <53DBD309.4000704@usdonovans.com> Date: Fri, 01 Aug 2014 12:48:57 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/v4d7IsH_9PEjSPcyXtPleGFZlnE Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 17:49:09 -0000 Lionel, The issue is that there could be multiple/many servers behind the agent=20 that is changing the Origin-Host. If one of them is overloaded and=20 generates a host report, clients will apply overload abatement to all=20 requests sent through that agent. The end result would be that the non=20 overloaded servers are under utilized. Steve On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: > Hi Steve, > > Not sure to understand. If an agent inserts its identity as Origin-host= in answers forwarded from servers, the client will see the agent as the = server. > What will be the added-value to add the identity of the server insertin= g the OLR if the client will store this information along the agent id? > Sorry if I've missed something... > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 > Cc : dime@ietf.org > Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 = Proposal) > > Somewhat on on the path toward generalization, we have a second issue > currently open that can be solved by having the DOIC node that inserts > an overload report in an answer message include it's own diameter > identity in the overload report. > > I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Ho= st. > > This issue points out that existing non DOIC agents are able to change > the origin-host in answer messages. One example of where this is done > is in topology hiding implementations. > > This issue can be addressed through attribution of overload reports. > > As such, I propose that we add a required AVP to the OC-OLR group AVP > that carries the diameter identity of the DOIC node that inserted the > overload report into the answer message. Issue #66 points out the need= > in host reports and issue #58 points out the need in realm reports. > > Steve > > > On 8/1/14, 9:54 AM, Ben Campbell wrote: >> +1 (modulo my comment to generalize) >> >> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >> >>> I believe Nirav's view requires all hosts in a realm to be the same v= endor and use a proprietary communication protocol to synchronize the hos= t report. Or, if a multiple (redundant or active-active) load-balancing a= gents are generating the report, they must similarly be synchronized. >>> =20 >>> Is seems like including the host name per Ulrich's suggestion is a si= mple way of avoiding proprietary mechanisms or coupling between hosts and= agents. >>> In some applications, the hosts can be completely decoupled (agnostic= about each other). I think it would be poor to add a synchronization req= uirement just to support DOIC. >>> =20 >>> -Dave >>> =20 >>> =20 >>> =20 >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@= orange.com >>> Sent: Friday, August 01, 2014 6:58 AM >>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>> Subject: Re: [Dime] DOIC issue #58 Proposal >>> =20 >>> Hi Steve, >>> =20 >>> I agree with Nirav's view. >>> =20 >>> Regards, >>> =20 >>> Lionel >>> =20 >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> =20 >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> =20 >>> Steve, >>> =20 >>> For this issue, I don't agree to include identity of the DOIC node th= at sends the report, into the realm reports. >>> =20 >>> In my view, the issue mentioned below - of two agents not 100% synchr= onize w.r.t the realm-report - is the related to "how agents synchronized= between themselves" and since that is not standardized we should not be = developing protocol solution for the case which occurs due to this out-of= -standards solution. >>> =20 >>> Besides, I don't see any issue due to slight miss-synchronization of = the realm-reports between two agents since they should still represent th= e realm load more or less accurately. >>> =20 >>> Also if the agents are not synchronized and if they are playing the r= ole of DOIC reacting node then they will apply abatement algorithm based = on different values (for the same realm). So it does not matter if the cl= ient does the same. >>> =20 >>> Finally, I don't see any value-add of using the "identity of the node= that sends the realm-report" to discard the other report related to the = same realm. In other words, this same logic can be achieved using sequenc= e-numbers as well, i.e. when the overload-report of an realm is active, t= he client is going to ignore all the reports of the same realm which has = lower sequence number value. So in essence, when two agents are sending r= ealm-reports, one of the reports is automatically ignored by the client i= f their sequence numbers differ. So the outcome without including the "id= entity if the node that sends realm report" is same as >>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>> =20 >>> Regards, >>> Nirav. >>> =20 >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Friday, August 01, 2014 1:23 AM >>> To: dime@ietf.org >>> Subject: [Dime] DOIC issue #58 Proposal >>> =20 >>> All, >>> >>> Issue #58 deals with the fact that there can be multiple senders of r= ealm overload report for the same realm. >>> >>> Ulrich proposes one aspect of what is required in the issue descripti= on: >>> >>> "In deployments where more than one node is configured to take the ro= le of a reporting node for realm-routed-request reports, reacting nodes m= ay receive in different answer messages different realm-routed-request ty= pe OLRs inserted by the different reporting nodes. Although it is expecte= d that the different reporting nodes report more or less the same content= , it cannot be expected that reports are 100% synchronized. Especially se= quence numbers may differ. To allow reacting nodes correctly detect outda= tes/replays/freshness of OLRs in this scenario, it is proposed that realm= -routed-request type OLRs are extended to contain the Diameter Identity o= f the reporting node that inserted the realm-routed-request type OLR. (e.= g. as already proposed in draft-donovan-dime-agent-overload-01). Reportin= g nodes that insert realm-routed-request type OLRs to answer messages MUS= T also insert their Diameter Identity. Reacting nodes MUST take the Diame= ter Identity received within the OLR into account in order to detect outd= ates/replays/freshness." >>> >>> I agree with Ulrich that realm reports must include the identity of t= he DOIC node that sends the report. This would be an optional AVP only r= equired for realm reports. It would not be required for host reports as = the identity of the sender of the host report is implicitly defined by th= e origin-host in the answer message. >>> >>> I also agree that the Diameter Identity of the reporting node be used= to determine if a received report is ignored or used to update existing = state. To this end I propose that we add wording that for the duration o= f a realm report, the reacting node only listens for updates to the realm= report from from the DOIC node that sent the realm report that resulted = in the realm OCS being stored. >>> >>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>> >>> Steve >>> >>> >>> _____________________________________________________________________= ____________________________________________________ >>> =20 >>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>> =20 >>> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>> _______________________________________________ >>> 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 > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Fri Aug 1 11:09:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2C1B27A7 for ; Fri, 1 Aug 2014 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNAXD2ME2EqE for ; Fri, 1 Aug 2014 11:09:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92921A031A for ; Fri, 1 Aug 2014 11:09:28 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 93B7F3B4A0C; Fri, 1 Aug 2014 20:09:26 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7891F35C048; Fri, 1 Aug 2014 20:09:26 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 20:09:26 +0200 From: To: Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u768Zg///5KYCAACW8wA== Date: Fri, 1 Aug 2014 18:09:25 +0000 Message-ID: <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> In-Reply-To: <53DBD309.4000704@usdonovans.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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.154818 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J1Y_B7DUC8bTgcHH1_D-Ujpqz6E Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:09:40 -0000 Hi Steve, So the topology hiding is not a relevant example here. Even with an identit= y inserted in the OLR, the client will never know to which server the reque= st is sent because the only relevant info for the client is the Origin-host= received in the answer i.e. the id of the agent. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: vendredi 1 ao=FBt 2014 19:49 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) Lionel, The issue is that there could be multiple/many servers behind the agent=20 that is changing the Origin-Host. If one of them is overloaded and=20 generates a host report, clients will apply overload abatement to all=20 requests sent through that agent. The end result would be that the non=20 overloaded servers are under utilized. Steve On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: > Hi Steve, > > Not sure to understand. If an agent inserts its identity as Origin-host i= n answers forwarded from servers, the client will see the agent as the serv= er. > What will be the added-value to add the identity of the server inserting = the OLR if the client will store this information along the agent id? > Sorry if I've missed something... > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 > Cc : dime@ietf.org > Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Pr= oposal) > > Somewhat on on the path toward generalization, we have a second issue > currently open that can be solved by having the DOIC node that inserts > an overload report in an answer message include it's own diameter > identity in the overload report. > > I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Host. > > This issue points out that existing non DOIC agents are able to change > the origin-host in answer messages. One example of where this is done > is in topology hiding implementations. > > This issue can be addressed through attribution of overload reports. > > As such, I propose that we add a required AVP to the OC-OLR group AVP > that carries the diameter identity of the DOIC node that inserted the > overload report into the answer message. Issue #66 points out the need > in host reports and issue #58 points out the need in realm reports. > > Steve > > > On 8/1/14, 9:54 AM, Ben Campbell wrote: >> +1 (modulo my comment to generalize) >> >> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >> >>> I believe Nirav's view requires all hosts in a realm to be the same ven= dor and use a proprietary communication protocol to synchronize the host re= port. Or, if a multiple (redundant or active-active) load-balancing agents = are generating the report, they must similarly be synchronized. >>>=20=20=20=20 >>> Is seems like including the host name per Ulrich's suggestion is a simp= le way of avoiding proprietary mechanisms or coupling between hosts and age= nts. >>> In some applications, the hosts can be completely decoupled (agnostic a= bout each other). I think it would be poor to add a synchronization require= ment just to support DOIC. >>>=20=20=20=20 >>> -Dave >>>=20=20=20=20 >>>=20=20=20=20 >>>=20=20=20=20 >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@or= ange.com >>> Sent: Friday, August 01, 2014 6:58 AM >>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>=20=20=20=20 >>> Hi Steve, >>>=20=20=20=20 >>> I agree with Nirav's view. >>>=20=20=20=20 >>> Regards, >>>=20=20=20=20 >>> Lionel >>>=20=20=20=20 >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>=20=20=20=20 >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>=20=20=20=20 >>> Steve, >>>=20=20=20=20 >>> For this issue, I don't agree to include identity of the DOIC node that= sends the report, into the realm reports. >>>=20=20=20=20 >>> In my view, the issue mentioned below - of two agents not 100% synchron= ize w.r.t the realm-report - is the related to "how agents synchronized bet= ween themselves" and since that is not standardized we should not be develo= ping protocol solution for the case which occurs due to this out-of-standar= ds solution. >>>=20=20=20=20 >>> Besides, I don't see any issue due to slight miss-synchronization of th= e realm-reports between two agents since they should still represent the re= alm load more or less accurately. >>>=20=20=20=20 >>> Also if the agents are not synchronized and if they are playing the rol= e of DOIC reacting node then they will apply abatement algorithm based on d= ifferent values (for the same realm). So it does not matter if the client d= oes the same. >>>=20=20=20=20 >>> Finally, I don't see any value-add of using the "identity of the node t= hat sends the realm-report" to discard the other report related to the same= realm. In other words, this same logic can be achieved using sequence-numb= ers as well, i.e. when the overload-report of an realm is active, the clien= t is going to ignore all the reports of the same realm which has lower sequ= ence number value. So in essence, when two agents are sending realm-reports= , one of the reports is automatically ignored by the client if their sequen= ce numbers differ. So the outcome without including the "identity if the no= de that sends realm report" is same as >>>> The effect should be that the reacting node will accept a realm report= from anyone when there is no active OLR for the realm but it will only lis= ten to one reporting node when it has an active report. >>>=20=20=20=20 >>> Regards, >>> Nirav. >>>=20=20=20=20 >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Friday, August 01, 2014 1:23 AM >>> To: dime@ietf.org >>> Subject: [Dime] DOIC issue #58 Proposal >>>=20=20=20=20 >>> All, >>> >>> Issue #58 deals with the fact that there can be multiple senders of rea= lm overload report for the same realm. >>> >>> Ulrich proposes one aspect of what is required in the issue description: >>> >>> "In deployments where more than one node is configured to take the role= of a reporting node for realm-routed-request reports, reacting nodes may r= eceive in different answer messages different realm-routed-request type OLR= s inserted by the different reporting nodes. Although it is expected that t= he different reporting nodes report more or less the same content, it canno= t be expected that reports are 100% synchronized. Especially sequence numbe= rs may differ. To allow reacting nodes correctly detect outdates/replays/fr= eshness of OLRs in this scenario, it is proposed that realm-routed-request = type OLRs are extended to contain the Diameter Identity of the reporting no= de that inserted the realm-routed-request type OLR. (e.g. as already propos= ed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert re= alm-routed-request type OLRs to answer messages MUST also insert their Diam= eter Identity. Reacting nodes MUST take the Diameter Identity received with= in the OLR into account in order to detect outdates/replays/freshness." >>> >>> I agree with Ulrich that realm reports must include the identity of the= DOIC node that sends the report. This would be an optional AVP only requi= red for realm reports. It would not be required for host reports as the id= entity of the sender of the host report is implicitly defined by the origin= -host in the answer message. >>> >>> I also agree that the Diameter Identity of the reporting node be used t= o determine if a received report is ignored or used to update existing stat= e. To this end I propose that we add wording that for the duration of a re= alm report, the reacting node only listens for updates to the realm report = from from the DOIC node that sent the realm report that resulted in the rea= lm OCS being stored. >>> >>> The effect should be that the reacting node will accept a realm report = from anyone when there is no active OLR for the realm but it will only list= en to one reporting node when it has an active report. >>> >>> Steve >>> >>> >>> _______________________________________________________________________= __________________________________________________ >>>=20=20=20=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >>>=20=20=20=20 >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 11:11:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E3F1A031A for ; Fri, 1 Aug 2014 11:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piqEHQkjIm4I for ; Fri, 1 Aug 2014 11:10:42 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73AC71B27A7 for ; Fri, 1 Aug 2014 11:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11137; q=dns/txt; s=iport; t=1406916633; x=1408126233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wKOvyhokU4ULlrXUHEVC5ubaZYUay361Y3Dv66D+2uc=; b=Grb4J3/IFVlRMAjtNsyRflWFvTtcV4+O1f8xnqdJafYJ49BWsCwwpxcN exJHa5wy2r9VPyUeYW+VWsK/LMm6AqMqn8d05teZyVgbK1qIw4oaxLEy0 jZRANl8L2F2vl0SO8qarl4LwIbM717MPDZbBDwn//aES5dPsk9+CH1G02 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFANfW21OtJV2b/2dsb2JhbABSCYMNUlcEzAYKh0wBgQsWd4QDAQEBBAEBAWQHCwwEAgEIDgMEAQEBCgsSBycLFAkIAgQBDQUIE4gnDckcEwSMCoJgBwoBHzEHBgSDJYEcBYpOjQGZBYNJbIEMOQ X-IronPort-AV: E=Sophos;i="5.01,781,1400025600"; d="scan'208";a="65857702" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 01 Aug 2014 18:10:32 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s71IAWFJ022028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 18:10:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 13:10:32 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "lionel.morand@orange.com" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8QG4AgAAZ2YD//7DrEA== Date: Fri, 1 Aug 2014 18:10:31 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> In-Reply-To: <53DBD309.4000704@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YWQtIfKsiZumeC4az-8nBG2ybZ4 Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:10:58 -0000 Steve, Can you explain how the inclusion of agent's identity in the host report so= lves the issue you have mentioned below? When the client (i.e. reacting node) receives overload report, it associate= s that with the Origin-Host present in the answer message. And if I remember correctly, we have had long discussion to arrive at this = handling. So I am not sure what would change when you add agent's identity = in the host report. Regards, Nirav.=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 11:19 PM To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Lionel, The issue is that there could be multiple/many servers behind the agent tha= t is changing the Origin-Host. If one of them is overloaded and generates = a host report, clients will apply overload abatement to all requests sent t= hrough that agent. The end result would be that the non overloaded servers= are under utilized. Steve On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: > Hi Steve, > > Not sure to understand. If an agent inserts its identity as Origin-host i= n answers forwarded from servers, the client will see the agent as the serv= er. > What will be the added-value to add the identity of the server inserting = the OLR if the client will store this information along the agent id? > Sorry if I've missed something... > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20 > Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 Cc : dime@ietf.org Objet : [Dime]= =20 > Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) > > Somewhat on on the path toward generalization, we have a second issue=20 > currently open that can be solved by having the DOIC node that inserts=20 > an overload report in an answer message include it's own diameter=20 > identity in the overload report. > > I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Host= . > > This issue points out that existing non DOIC agents are able to change=20 > the origin-host in answer messages. One example of where this is done=20 > is in topology hiding implementations. > > This issue can be addressed through attribution of overload reports. > > As such, I propose that we add a required AVP to the OC-OLR group AVP=20 > that carries the diameter identity of the DOIC node that inserted the=20 > overload report into the answer message. Issue #66 points out the=20 > need in host reports and issue #58 points out the need in realm reports. > > Steve > > > On 8/1/14, 9:54 AM, Ben Campbell wrote: >> +1 (modulo my comment to generalize) >> >> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >> >>> I believe Nirav's view requires all hosts in a realm to be the same ven= dor and use a proprietary communication protocol to synchronize the host re= port. Or, if a multiple (redundant or active-active) load-balancing agents = are generating the report, they must similarly be synchronized. >>> =20 >>> Is seems like including the host name per Ulrich's suggestion is a simp= le way of avoiding proprietary mechanisms or coupling between hosts and age= nts. >>> In some applications, the hosts can be completely decoupled (agnostic a= bout each other). I think it would be poor to add a synchronization require= ment just to support DOIC. >>> =20 >>> -Dave >>> =20 >>> =20 >>> =20 >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>> lionel.morand@orange.com >>> Sent: Friday, August 01, 2014 6:58 AM >>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>> Subject: Re: [Dime] DOIC issue #58 Proposal >>> =20 >>> Hi Steve, >>> =20 >>> I agree with Nirav's view. >>> =20 >>> Regards, >>> =20 >>> Lionel >>> =20 >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> =20 >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> =20 >>> Steve, >>> =20 >>> For this issue, I don't agree to include identity of the DOIC node that= sends the report, into the realm reports. >>> =20 >>> In my view, the issue mentioned below - of two agents not 100% synchron= ize w.r.t the realm-report - is the related to "how agents synchronized bet= ween themselves" and since that is not standardized we should not be develo= ping protocol solution for the case which occurs due to this out-of-standar= ds solution. >>> =20 >>> Besides, I don't see any issue due to slight miss-synchronization of th= e realm-reports between two agents since they should still represent the re= alm load more or less accurately. >>> =20 >>> Also if the agents are not synchronized and if they are playing the rol= e of DOIC reacting node then they will apply abatement algorithm based on d= ifferent values (for the same realm). So it does not matter if the client d= oes the same. >>> =20 >>> Finally, I don't see any value-add of using the "identity of the=20 >>> node that sends the realm-report" to discard the other report=20 >>> related to the same realm. In other words, this same logic can be=20 >>> achieved using sequence-numbers as well, i.e. when the=20 >>> overload-report of an realm is active, the client is going to ignore=20 >>> all the reports of the same realm which has lower sequence number=20 >>> value. So in essence, when two agents are sending realm-reports, one=20 >>> of the reports is automatically ignored by the client if their=20 >>> sequence numbers differ. So the outcome without including the=20 >>> "identity if the node that sends realm report" is same as >>>> The effect should be that the reacting node will accept a realm report= from anyone when there is no active OLR for the realm but it will only lis= ten to one reporting node when it has an active report. >>> =20 >>> Regards, >>> Nirav. >>> =20 >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Friday, August 01, 2014 1:23 AM >>> To: dime@ietf.org >>> Subject: [Dime] DOIC issue #58 Proposal >>> =20 >>> All, >>> >>> Issue #58 deals with the fact that there can be multiple senders of rea= lm overload report for the same realm. >>> >>> Ulrich proposes one aspect of what is required in the issue description= : >>> >>> "In deployments where more than one node is configured to take the role= of a reporting node for realm-routed-request reports, reacting nodes may r= eceive in different answer messages different realm-routed-request type OLR= s inserted by the different reporting nodes. Although it is expected that t= he different reporting nodes report more or less the same content, it canno= t be expected that reports are 100% synchronized. Especially sequence numbe= rs may differ. To allow reacting nodes correctly detect outdates/replays/fr= eshness of OLRs in this scenario, it is proposed that realm-routed-request = type OLRs are extended to contain the Diameter Identity of the reporting no= de that inserted the realm-routed-request type OLR. (e.g. as already propos= ed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert re= alm-routed-request type OLRs to answer messages MUST also insert their Diam= eter Identity. Reacting nodes MUST take the Diameter Identity received with= in the OLR into account in order to detect outdates/replays/freshness." >>> >>> I agree with Ulrich that realm reports must include the identity of the= DOIC node that sends the report. This would be an optional AVP only requi= red for realm reports. It would not be required for host reports as the id= entity of the sender of the host report is implicitly defined by the origin= -host in the answer message. >>> >>> I also agree that the Diameter Identity of the reporting node be used t= o determine if a received report is ignored or used to update existing stat= e. To this end I propose that we add wording that for the duration of a re= alm report, the reacting node only listens for updates to the realm report = from from the DOIC node that sent the realm report that resulted in the rea= lm OCS being stored. >>> >>> The effect should be that the reacting node will accept a realm report = from anyone when there is no active OLR for the realm but it will only list= en to one reporting node when it has an active report. >>> >>> Steve >>> >>> >>> ____________________________________________________________________ >>> _____________________________________________________ >>> =20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> =20 >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Aug 1 11:28:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE71B2897 for ; Fri, 1 Aug 2014 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbj1kISXa5pA for ; Fri, 1 Aug 2014 11:28:20 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9161A031A for ; Fri, 1 Aug 2014 11:28:20 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49959 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDHYv-0000hH-Kc; Fri, 01 Aug 2014 11:28:19 -0700 Message-ID: <53DBDC42.3060007@usdonovans.com> Date: Fri, 01 Aug 2014 13:28:18 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "lionel.morand@orange.com" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s3b66uUEt3Sharfp1YIqnQhvTyU Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:28:28 -0000 Nirav, It would not be the agents identity in this case, it would be the=20 identity of the server. This is to fix the fact that the agent is=20 putting it's own identity in the origin-host AVP. Steve On 8/1/14, 1:10 PM, Nirav Salot (nsalot) wrote: > Steve, > > Can you explain how the inclusion of agent's identity in the host repor= t solves the issue you have mentioned below? > > When the client (i.e. reacting node) receives overload report, it assoc= iates that with the Origin-Host present in the answer message. > And if I remember correctly, we have had long discussion to arrive at t= his handling. So I am not sure what would change when you add agent's ide= ntity in the host report. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Friday, August 01, 2014 11:19 PM > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > Lionel, > > The issue is that there could be multiple/many servers behind the agent= that is changing the Origin-Host. If one of them is overloaded and gene= rates a host report, clients will apply overload abatement to all request= s sent through that agent. The end result would be that the non overload= ed servers are under utilized. > > Steve > > On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> Not sure to understand. If an agent inserts its identity as Origin-hos= t in answers forwarded from servers, the client will see the agent as the= server. >> What will be the added-value to add the identity of the server inserti= ng the OLR if the client will store this information along the agent id? >> Sorry if I've missed something... >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 Cc : dime@ietf.org Objet : [Di= me] >> Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) >> >> Somewhat on on the path toward generalization, we have a second issue >> currently open that can be solved by having the DOIC node that inserts= >> an overload report in an answer message include it's own diameter >> identity in the overload report. >> >> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >> >> This issue points out that existing non DOIC agents are able to change= >> the origin-host in answer messages. One example of where this is done= >> is in topology hiding implementations. >> >> This issue can be addressed through attribution of overload reports. >> >> As such, I propose that we add a required AVP to the OC-OLR group AVP >> that carries the diameter identity of the DOIC node that inserted the >> overload report into the answer message. Issue #66 points out the >> need in host reports and issue #58 points out the need in realm report= s. >> >> Steve >> >> >> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>> +1 (modulo my comment to generalize) >>> >>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote:= >>> >>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the ho= st report. Or, if a multiple (redundant or active-active) load-balancing = agents are generating the report, they must similarly be synchronized. >>>> =20 >>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization re= quirement just to support DOIC. >>>> =20 >>>> -Dave >>>> =20 >>>> =20 >>>> =20 >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>> lionel.morand@orange.com >>>> Sent: Friday, August 01, 2014 6:58 AM >>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>> =20 >>>> Hi Steve, >>>> =20 >>>> I agree with Nirav's view. >>>> =20 >>>> Regards, >>>> =20 >>>> Lionel >>>> =20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> =20 >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> =20 >>>> Steve, >>>> =20 >>>> For this issue, I don't agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >>>> =20 >>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronize= d between themselves" and since that is not standardized we should not be= developing protocol solution for the case which occurs due to this out-o= f-standards solution. >>>> =20 >>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >>>> =20 >>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based= on different values (for the same realm). So it does not matter if the c= lient does the same. >>>> =20 >>>> Finally, I don't see any value-add of using the "identity of the >>>> node that sends the realm-report" to discard the other report >>>> related to the same realm. In other words, this same logic can be >>>> achieved using sequence-numbers as well, i.e. when the >>>> overload-report of an realm is active, the client is going to ignore= >>>> all the reports of the same realm which has lower sequence number >>>> value. So in essence, when two agents are sending realm-reports, one= >>>> of the reports is automatically ignored by the client if their >>>> sequence numbers differ. So the outcome without including the >>>> "identity if the node that sends realm report" is same as >>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>> =20 >>>> Regards, >>>> Nirav. >>>> =20 >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan= >>>> Sent: Friday, August 01, 2014 1:23 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] DOIC issue #58 Proposal >>>> =20 >>>> All, >>>> >>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>> >>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>> >>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes = may receive in different answer messages different realm-routed-request t= ype OLRs inserted by the different reporting nodes. Although it is expect= ed that the different reporting nodes report more or less the same conten= t, it cannot be expected that reports are 100% synchronized. Especially s= equence numbers may differ. To allow reacting nodes correctly detect outd= ates/replays/freshness of OLRs in this scenario, it is proposed that real= m-routed-request type OLRs are extended to contain the Diameter Identity = of the reporting node that inserted the realm-routed-request type OLR. (e= =2Eg. as already proposed in draft-donovan-dime-agent-overload-01). Repor= ting nodes that insert realm-routed-request type OLRs to answer messages = MUST also insert their Diameter Identity. Reacting nodes MUST take the Di= ameter Identity received within the OLR into account in order to detect o= utdates/replays/freshness." >>>> >>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports as= the identity of the sender of the host report is implicitly defined by t= he origin-host in the answer message. >>>> >>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing= state. To this end I propose that we add wording that for the duration = of a realm report, the reacting node only listens for updates to the real= m report from from the DOIC node that sent the realm report that resulted= in the realm OCS being stored. >>>> >>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>> >>>> Steve >>>> >>>> >>>> ____________________________________________________________________= >>>> _____________________________________________________ >>>> =20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant susc= eptibles d'alteration, Orange decline toute responsabilite si ce message = a ete altere, deforme ou falsifie. Merci. >>>> =20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>> Thank you. >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> ______________________________________________________________________= >> ___________________________________________________ >> >> 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 q= ue les pieces jointes. Les messages electroniques etant susceptibles d'al= teration, 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 b= e 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. >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Aug 1 11:29:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517C71A8BB7 for ; Fri, 1 Aug 2014 11:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsLVWOmIlyHU for ; Fri, 1 Aug 2014 11:29:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A611B288F for ; Fri, 1 Aug 2014 11:29:50 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49961 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDHaN-0002Qo-PZ; Fri, 01 Aug 2014 11:29:49 -0700 Message-ID: <53DBDC9C.2040703@usdonovans.com> Date: Fri, 01 Aug 2014 13:29:48 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DUFdkmIt5-r9hYLhlFPR6rWM-qc Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:29:54 -0000 Lionel, The agent would not be inserting it's identity in the overload report. =20 The proposal is that the DOIC node that inserted the overload report=20 includes its diameter identity in the overload report. As such, it=20 would be the server's identity that is in the overload report. Sorry if I wasn't clear. Steve On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: > Hi Steve, > > So the topology hiding is not a relevant example here. Even with an ide= ntity inserted in the OLR, the client will never know to which server the= request is sent because the only relevant info for the client is the Ori= gin-host received in the answer i.e. the id of the agent. > > Regards, > > Lionel > > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) > > Lionel, > > The issue is that there could be multiple/many servers behind the agent= > that is changing the Origin-Host. If one of them is overloaded and > generates a host report, clients will apply overload abatement to all > requests sent through that agent. The end result would be that the non= > overloaded servers are under utilized. > > Steve > > On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> Not sure to understand. If an agent inserts its identity as Origin-hos= t in answers forwarded from servers, the client will see the agent as the= server. >> What will be the added-value to add the identity of the server inserti= ng the OLR if the client will store this information along the agent id? >> Sorry if I've missed something... >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >> Cc : dime@ietf.org >> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) >> >> Somewhat on on the path toward generalization, we have a second issue >> currently open that can be solved by having the DOIC node that inserts= >> an overload report in an answer message include it's own diameter >> identity in the overload report. >> >> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >> >> This issue points out that existing non DOIC agents are able to change= >> the origin-host in answer messages. One example of where this is done= >> is in topology hiding implementations. >> >> This issue can be addressed through attribution of overload reports. >> >> As such, I propose that we add a required AVP to the OC-OLR group AVP >> that carries the diameter identity of the DOIC node that inserted the >> overload report into the answer message. Issue #66 points out the nee= d >> in host reports and issue #58 points out the need in realm reports. >> >> Steve >> >> >> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>> +1 (modulo my comment to generalize) >>> >>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote:= >>> >>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the ho= st report. Or, if a multiple (redundant or active-active) load-balancing = agents are generating the report, they must similarly be synchronized. >>>> =20 >>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization re= quirement just to support DOIC. >>>> =20 >>>> -Dave >>>> =20 >>>> =20 >>>> =20 >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand= @orange.com >>>> Sent: Friday, August 01, 2014 6:58 AM >>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>> =20 >>>> Hi Steve, >>>> =20 >>>> I agree with Nirav's view. >>>> =20 >>>> Regards, >>>> =20 >>>> Lionel >>>> =20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> =20 >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> =20 >>>> Steve, >>>> =20 >>>> For this issue, I don't agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >>>> =20 >>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronize= d between themselves" and since that is not standardized we should not be= developing protocol solution for the case which occurs due to this out-o= f-standards solution. >>>> =20 >>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >>>> =20 >>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based= on different values (for the same realm). So it does not matter if the c= lient does the same. >>>> =20 >>>> Finally, I don't see any value-add of using the "identity of the nod= e that sends the realm-report" to discard the other report related to the= same realm. In other words, this same logic can be achieved using sequen= ce-numbers as well, i.e. when the overload-report of an realm is active, = the client is going to ignore all the reports of the same realm which has= lower sequence number value. So in essence, when two agents are sending = realm-reports, one of the reports is automatically ignored by the client = if their sequence numbers differ. So the outcome without including the "i= dentity if the node that sends realm report" is same as >>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>> =20 >>>> Regards, >>>> Nirav. >>>> =20 >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan= >>>> Sent: Friday, August 01, 2014 1:23 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] DOIC issue #58 Proposal >>>> =20 >>>> All, >>>> >>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>> >>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>> >>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes = may receive in different answer messages different realm-routed-request t= ype OLRs inserted by the different reporting nodes. Although it is expect= ed that the different reporting nodes report more or less the same conten= t, it cannot be expected that reports are 100% synchronized. Especially s= equence numbers may differ. To allow reacting nodes correctly detect outd= ates/replays/freshness of OLRs in this scenario, it is proposed that real= m-routed-request type OLRs are extended to contain the Diameter Identity = of the reporting node that inserted the realm-routed-request type OLR. (e= =2Eg. as already proposed in draft-donovan-dime-agent-overload-01). Repor= ting nodes that insert realm-routed-request type OLRs to answer messages = MUST also insert their Diameter Identity. Reacting nodes MUST take the Di= ameter Identity received within the OLR into account in order to detect o= utdates/replays/freshness." >>>> >>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports as= the identity of the sender of the host report is implicitly defined by t= he origin-host in the answer message. >>>> >>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing= state. To this end I propose that we add wording that for the duration = of a realm report, the reacting node only listens for updates to the real= m report from from the DOIC node that sent the realm report that resulted= in the realm OCS being stored. >>>> >>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>> >>>> Steve >>>> >>>> >>>> ____________________________________________________________________= _____________________________________________________ >>>> =20 >>>> Ce message et ses pieces jointes peuvent contenir des informations c= onfidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>> =20 >>>> This message and its attachments may contain confidential or privile= ged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation= =2E >>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>> Thank you. >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d 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. >> >> > > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Fri Aug 1 11:45:24 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DEA1A0AEC for ; Fri, 1 Aug 2014 11:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPL_vEfdf5WB for ; Fri, 1 Aug 2014 11:45:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ED11A0303 for ; Fri, 1 Aug 2014 11:45:15 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 394D72ACE50; Fri, 1 Aug 2014 20:45:11 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 14AF015804E; Fri, 1 Aug 2014 20:45:11 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 20:45:10 +0200 From: To: Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u768Zg///5KYCAACW8wP//5a4AgAAl0h4= Date: Fri, 1 Aug 2014 18:45:10 +0000 Message-ID: <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> In-Reply-To: <53DBDC9C.2040703@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.154818 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/b3HhUGpdzl_VTq208uxqDPQrAvI Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:45:23 -0000 I understood! But what will be the use of this info by the client? As for t= he client, the server is the identity of the Origin-host of the received an= swer. Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- Lionel, The agent would not be inserting it's identity in the overload report. The proposal is that the DOIC node that inserted the overload report includes its diameter identity in the overload report. As such, it would be the server's identity that is in the overload report. Sorry if I wasn't clear. Steve On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: > Hi Steve, > > So the topology hiding is not a relevant example here. Even with an ident= ity inserted in the OLR, the client will never know to which server the req= uest is sent because the only relevant info for the client is the Origin-ho= st received in the answer i.e. the id of the agent. > > Regards, > > Lionel > > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) > > Lionel, > > The issue is that there could be multiple/many servers behind the agent > that is changing the Origin-Host. If one of them is overloaded and > generates a host report, clients will apply overload abatement to all > requests sent through that agent. The end result would be that the non > overloaded servers are under utilized. > > Steve > > On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> Not sure to understand. If an agent inserts its identity as Origin-host = in answers forwarded from servers, the client will see the agent as the ser= ver. >> What will be the added-value to add the identity of the server inserting= the OLR if the client will store this information along the agent id? >> Sorry if I've missed something... >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >> Cc : dime@ietf.org >> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 P= roposal) >> >> Somewhat on on the path toward generalization, we have a second issue >> currently open that can be solved by having the DOIC node that inserts >> an overload report in an answer message include it's own diameter >> identity in the overload report. >> >> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Hos= t. >> >> This issue points out that existing non DOIC agents are able to change >> the origin-host in answer messages. One example of where this is done >> is in topology hiding implementations. >> >> This issue can be addressed through attribution of overload reports. >> >> As such, I propose that we add a required AVP to the OC-OLR group AVP >> that carries the diameter identity of the DOIC node that inserted the >> overload report into the answer message. Issue #66 points out the need >> in host reports and issue #58 points out the need in realm reports. >> >> Steve >> >> >> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>> +1 (modulo my comment to generalize) >>> >>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>> >>>> I believe Nirav's view requires all hosts in a realm to be the same ve= ndor and use a proprietary communication protocol to synchronize the host r= eport. Or, if a multiple (redundant or active-active) load-balancing agents= are generating the report, they must similarly be synchronized. >>>> >>>> Is seems like including the host name per Ulrich's suggestion is a sim= ple way of avoiding proprietary mechanisms or coupling between hosts and ag= ents. >>>> In some applications, the hosts can be completely decoupled (agnostic = about each other). I think it would be poor to add a synchronization requir= ement just to support DOIC. >>>> >>>> -Dave >>>> >>>> >>>> >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@o= range.com >>>> Sent: Friday, August 01, 2014 6:58 AM >>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>> >>>> Hi Steve, >>>> >>>> I agree with Nirav's view. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> >>>> Steve, >>>> >>>> For this issue, I don't agree to include identity of the DOIC node tha= t sends the report, into the realm reports. >>>> >>>> In my view, the issue mentioned below - of two agents not 100% synchro= nize w.r.t the realm-report - is the related to "how agents synchronized be= tween themselves" and since that is not standardized we should not be devel= oping protocol solution for the case which occurs due to this out-of-standa= rds solution. >>>> >>>> Besides, I don't see any issue due to slight miss-synchronization of t= he realm-reports between two agents since they should still represent the r= ealm load more or less accurately. >>>> >>>> Also if the agents are not synchronized and if they are playing the ro= le of DOIC reacting node then they will apply abatement algorithm based on = different values (for the same realm). So it does not matter if the client = does the same. >>>> >>>> Finally, I don't see any value-add of using the "identity of the node = that sends the realm-report" to discard the other report related to the sam= e realm. In other words, this same logic can be achieved using sequence-num= bers as well, i.e. when the overload-report of an realm is active, the clie= nt is going to ignore all the reports of the same realm which has lower seq= uence number value. So in essence, when two agents are sending realm-report= s, one of the reports is automatically ignored by the client if their seque= nce numbers differ. So the outcome without including the "identity if the n= ode that sends realm report" is same as >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>> >>>> Regards, >>>> Nirav. >>>> >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>>> Sent: Friday, August 01, 2014 1:23 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] DOIC issue #58 Proposal >>>> >>>> All, >>>> >>>> Issue #58 deals with the fact that there can be multiple senders of re= alm overload report for the same realm. >>>> >>>> Ulrich proposes one aspect of what is required in the issue descriptio= n: >>>> >>>> "In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that = the different reporting nodes report more or less the same content, it cann= ot be expected that reports are 100% synchronized. Especially sequence numb= ers may differ. To allow reacting nodes correctly detect outdates/replays/f= reshness of OLRs in this scenario, it is proposed that realm-routed-request= type OLRs are extended to contain the Diameter Identity of the reporting n= ode that inserted the realm-routed-request type OLR. (e.g. as already propo= sed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert r= ealm-routed-request type OLRs to answer messages MUST also insert their Dia= meter Identity. Reacting nodes MUST take the Diameter Identity received wit= hin the OLR into account in order to detect outdates/replays/freshness." >>>> >>>> I agree with Ulrich that realm reports must include the identity of th= e DOIC node that sends the report. This would be an optional AVP only requ= ired for realm reports. It would not be required for host reports as the i= dentity of the sender of the host report is implicitly defined by the origi= n-host in the answer message. >>>> >>>> I also agree that the Diameter Identity of the reporting node be used = to determine if a received report is ignored or used to update existing sta= te. To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report= from from the DOIC node that sent the realm report that resulted in the re= alm OCS being stored. >>>> >>>> The effect should be that the reacting node will accept a realm report= from anyone when there is no active OLR for the realm but it will only lis= ten to one reporting node when it has an active report. >>>> >>>> Steve >>>> >>>> >>>> ______________________________________________________________________= ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privilege= d 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. >>>> _______________________________________________ >>>> 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 >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 11:47:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3DF1B2899 for ; Fri, 1 Aug 2014 11:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MBldIM2GERI for ; Fri, 1 Aug 2014 11:47:11 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5EF1A0303 for ; Fri, 1 Aug 2014 11:47:11 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49976 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDHr8-0007v2-T4; Fri, 01 Aug 2014 11:47:10 -0700 Message-ID: <53DBE0AB.4040505@usdonovans.com> Date: Fri, 01 Aug 2014 13:47:07 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "lionel.morand@orange.com" , Dave Dolson , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050506080007020602060307" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LSV2NxoH2HzVkAMnuXoX13AFlM8 Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:47:18 -0000 This is a multi-part message in MIME format. --------------050506080007020602060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The question becomes, what happens if the nodes that are sending the realm reports lose the ability to stay in synchronization. We all know that communication can be lost between entities. This is what leads to complicated, multiple stage protocols for things like database synchronization. So, lets assume that we mandate that DOIC nodes that send realm reports (let's call them realm report generators) MUST be in sync and that includes both the sequence number and any abatement algorithm data (percentage reduction for the loss algorithm). A side note -- let's stop assuming that the realm report generator is an agent. There is nothing saying that agents are the only thing that can send realm reports. It is perfectly valid for servers to send realm report if they have visibility to the state of the realm as a whole. Now, assume that the realm report generators lose the ability to communicate due to some localized failure. The realm is known to be overloaded so realm reports need to be sent. Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed. A client is going to see both reports types. The realm report generators are going to refresh the reports, sending new reports with higher sequence numbers. The client will honor all reports that have a bigger sequence number. One effect can be a thrashing between 10% reduction and 50% reduction. This is clearly an edge case. It is, however, an edge case that is easily avoidable by attributing the source of the realm report. Steve On 8/1/14, 11:12 AM, Nirav Salot (nsalot) wrote: > > Hi Dave, > > On top of what Lionel mentioned, if you look at issue #58, we are > already assuming that agents providing report for the same realm are > almost synchronized. > > > Although it is expected that the different reporting nodes report > more or less the same content, it cannot be expected that reports are > 100% synchronized. Especially sequence numbers may differ. > > The issue we are solving is when there is slight miss-synchronization > between those agents -- for whatever reason -- how does the client > handle it. > > > To allow reacting nodes correctly detect outdates/replays/freshness > of OLRs in this scenario, it is proposed that realm-routed-request > type OLRs are extended to contain the Diameter Identity of the > reporting node that inserted the realm-routed-request type OLR. > > And that's where we are proposing to use "identity of agent providing > realm report". The client receives same report with two different > identities (from two different agents) and discard one of them. > > > Reacting nodes MUST take the Diameter Identity received within the > OLR into account in order to detect outdates/replays/freshness. > > My main point was that, the same logic -- of discarding report from > one of the agent -- can be achieved by using sequence number, which is > already provided as part of overload report. > > So in summary, there is no value in adding "Diameter identity of the > agent providing realm-report" for issue #58. > > Just to clarify, I am not assuming same vendor providing the agents. > And, I guess, that is not relevant to issue #58. > > Regards, > > Nirav. > > *From:*lionel.morand@orange.com [mailto:lionel.morand@orange.com] > *Sent:* Friday, August 01, 2014 9:28 PM > *To:* Dave Dolson; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) > *Subject:* RE: [Dime] DOIC issue #58 Proposal > > Hi Dave, > > The whole purpose of "Realm" report is to provide a consolidated view > of the overload status of all the servers in the realm. > > If you are not able to provide such consolidated view for the entire > realm, you will not be able to send OLR with the type "Realm". > > The synchronization between nodes might not be required but it is > required that all the agents providing Realm-based OLR have the means > to provide a "common" view, whatever the mechanism used for that. > > Lionel > > *De :*Dave Dolson [mailto:ddolson@sandvine.com] > *Envoyé :* vendredi 1 août 2014 16:50 > *À :* MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org > ; Nirav Salot (nsalot) > *Objet :* RE: [Dime] DOIC issue #58 Proposal > > I believe Nirav's view requires all hosts in a realm to be the same > vendor and use a proprietary communication protocol to synchronize the > host report. Or, if a multiple (redundant or active-active) > load-balancing agents are generating the report, they must similarly > be synchronized. > > Is seems like including the host name per Ulrich's suggestion is a > simple way of avoiding proprietary mechanisms or coupling between > hosts and agents. > > In some applications, the hosts can be completely decoupled (agnostic > about each other). I think it would be poor to add a synchronization > requirement just to support DOIC. > > -Dave > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of > *lionel.morand@orange.com > *Sent:* Friday, August 01, 2014 6:58 AM > *To:* Steve Donovan; dime@ietf.org ; Nirav Salot > (nsalot) > *Subject:* Re: [Dime] DOIC issue #58 Proposal > > Hi Steve, > > I agree with Nirav's view. > > Regards, > > Lionel > > Envoyé depuis mon Sony Xperia SP d'Orange > > ---- Nirav Salot (nsalot) a écrit ---- > > > Steve, > > For this issue, I don't agree to include identity of the DOIC node > that sends the report, into the realm reports. > > In my view, the issue mentioned below -- of two agents not 100% > synchronize w.r.t the realm-report -- is the related to "how agents > synchronized between themselves" and since that is not standardized we > should not be developing protocol solution for the case which occurs > due to this out-of-standards solution. > > Besides, I don't see any issue due to slight miss-synchronization of > the realm-reports between two agents since they should still represent > the realm load more or less accurately. > > Also if the agents are not synchronized and if they are playing the > role of DOIC reacting node then they will apply abatement algorithm > based on different values (for the same realm). So it does not matter > if the client does the same. > > Finally, I don't see any value-add of using the "identity of the node > that sends the realm-report" to discard the other report related to > the same realm. In other words, this same logic can be achieved using > sequence-numbers as well, i.e. when the overload-report of an realm is > active, the client is going to ignore all the reports of the same > realm which has lower sequence number value. So in essence, when two > agents are sending realm-reports, one of the reports is automatically > ignored by the client if their sequence numbers differ. So the outcome > without including the "identity if the node that sends realm report" > is same as > > >The effect should be that the reacting node will accept a realm > report from anyone when there is no active OLR for the realm but it > will only listen to one reporting node when it has an active report. > > Regards, > > Nirav. > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan > *Sent:* Friday, August 01, 2014 1:23 AM > *To:* dime@ietf.org > *Subject:* [Dime] DOIC issue #58 Proposal > > All, > > Issue #58 deals with the fact that there can be multiple senders of > realm overload report for the same realm. > > Ulrich proposes one aspect of what is required in the issue description: > > "In deployments where more than one node is configured to take the > role of a reporting node for realm-routed-request reports, reacting > nodes may receive in different answer messages different > realm-routed-request type OLRs inserted by the different reporting > nodes. Although it is expected that the different reporting nodes > report more or less the same content, it cannot be expected that > reports are 100% synchronized. Especially sequence numbers may differ. > To allow reacting nodes correctly detect outdates/replays/freshness of > OLRs in this scenario, it is proposed that realm-routed-request type > OLRs are extended to contain the Diameter Identity of the reporting > node that inserted the realm-routed-request type OLR. (e.g. as already > proposed in draft-donovan-dime-agent-overload-01 > ). > Reporting nodes that insert realm-routed-request type OLRs to answer > messages MUST also insert their Diameter Identity. Reacting nodes MUST > take the Diameter Identity received within the OLR into account in > order to detect outdates/replays/freshness. " > > I agree with Ulrich that realm reports must include the identity of > the DOIC node that sends the report. This would be an optional AVP > only required for realm reports. It would not be required for host > reports as the identity of the sender of the host report is implicitly > defined by the origin-host in the answer message. > > I also agree that the Diameter Identity of the reporting node be used > to determine if a received report is ignored or used to update > existing state. To this end I propose that we add wording that for > the duration of a realm report, the reacting node only listens for > updates to the realm report from from the DOIC node that sent the > realm report that resulted in the realm OCS being stored. > > The effect should be that the reacting node will accept a realm report > from anyone when there is no active OLR for the realm but it will only > listen to one reporting node when it has an active report. > > Steve > > _________________________________________________________________________________________________________________________ > > 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. > _________________________________________________________________________________________________________________________ > > 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. --------------050506080007020602060307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The question becomes, what happens if the nodes that are sending the realm reports lose the ability to stay in synchronization.  We all know that communication can be lost between entities.  This is what leads to complicated, multiple stage protocols for things like database synchronization.

So, lets assume that we mandate that DOIC nodes that send realm reports (let's call them realm report generators) MUST be in sync and that includes both the sequence number and any abatement algorithm data (percentage reduction for the loss algorithm).

A side note -- let's stop assuming that the realm report generator is an agent.  There is nothing saying that agents are the only thing that can send realm reports.  It is perfectly valid for servers to send realm report if they have visibility to the state of the realm as a whole.

Now, assume that the realm report generators lose the ability to communicate due to some localized failure.  The realm is known to be overloaded so realm reports need to be sent.  Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed.

A client is going to see both reports types.  The realm report generators are going to refresh the reports, sending new reports with higher sequence numbers.  The client will honor all reports that have a bigger sequence number. 

One effect can be a thrashing between 10% reduction and 50% reduction.

This is clearly an edge case.  It is, however, an edge case that is easily avoidable by attributing the source of the realm report.

Steve


On 8/1/14, 11:12 AM, Nirav Salot (nsalot) wrote:

Hi Dave,

 

On top of what Lionel mentioned, if you look at issue #58, we are already assuming that agents providing report for the same realm are almost synchronized.

> Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ.

The issue we are solving is when there is slight miss-synchronization between those agents – for whatever reason – how does the client handle it.

> To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR.

 

And that’s where we are proposing to use "identity of agent providing realm report". The client receives same report with two different identities (from two different agents) and discard one of them.

> Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness.

My main point was that, the same logic – of discarding report from one of the agent – can be achieved by using sequence number, which is already provided as part of overload report.

So in summary, there is no value in adding "Diameter identity of the agent providing realm-report" for issue #58.

 

Just to clarify, I am not assuming same vendor providing the agents. And, I guess, that is not relevant to issue #58.

 

Regards,

Nirav.

 

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Friday, August 01, 2014 9:28 PM
To: Dave Dolson; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Subject: RE: [Dime] DOIC issue #58 Proposal

 

Hi Dave,

 

The whole purpose of "Realm" report is to provide a consolidated view of the overload status of all the servers in the realm.

If you are not able to provide such consolidated view for the entire realm, you will not be able to send OLR with the type "Realm".

The synchronization between nodes might not be required but it is required that all the agents providing Realm-based OLR have the means to provide a "common" view, whatever the mechanism used for that.

 

Lionel

 

 

De : Dave Dolson [mailto:ddolson@sandvine.com]
Envoyé : vendredi 1 août 2014 16:50
À : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Objet : RE: [Dime] DOIC issue #58 Proposal

 

I believe Nirav’s view requires all hosts in a realm to be the same vendor and use a proprietary communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are generating the report, they must similarly be synchronized.

 

Is seems like including the host name per Ulrich’s suggestion is a simple way of avoiding proprietary mechanisms or coupling between hosts and agents.

In some applications, the hosts can be completely decoupled (agnostic about each other). I think it would be poor to add a synchronization requirement just to support DOIC.

 

-Dave

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Friday, August 01, 2014 6:58 AM
To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Subject: Re: [Dime] DOIC issue #58 Proposal

 

Hi Steve,
 
I agree with Nirav's view. 
 
Regards,
 
Lionel 
 
Envoyé depuis mon Sony Xperia SP d'Orange
 
---- Nirav Salot (nsalot) a écrit ----
 

Steve,

 

For this issue, I don’t agree to include identity of the DOIC node that sends the report, into the realm reports.

 

In my view, the issue mentioned below – of two agents not 100% synchronize w.r.t the realm-report – is the related to "how agents synchronized between themselves" and since that is not standardized we should not be developing protocol solution for the case which occurs due to this out-of-standards solution.

 

Besides, I don’t see any issue due to slight miss-synchronization of the realm-reports between two agents since they should still represent the realm load more or less accurately.

 

Also if the agents are not synchronized and if they are playing the role of DOIC reacting node then they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same.

 

Finally, I don’t see any value-add of using the "identity of the node that sends the realm-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as well, i.e. when the overload-report of an realm is active, the client is going to ignore all the reports of the same realm which has lower sequence number value. So in essence, when two agents are sending realm-reports, one of the reports is automatically ignored by the client if their sequence numbers differ. So the outcome without including the "identity if the node that sends realm report" is same as

>The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: dime@ietf.org
Subject: [Dime] DOIC issue #58 Proposal

 

All,

Issue #58 deals with the fact that there can be multiple senders of realm overload report for the same realm. 

Ulrich proposes one aspect of what is required in the issue description:

"In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report.  This would be an optional AVP only required for realm reports.  It would not be required for host reports as the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state.  To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report.

Steve

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

--------------050506080007020602060307-- From nobody Fri Aug 1 11:57:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D111B2895 for ; Fri, 1 Aug 2014 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYO4zseHFqoA for ; Fri, 1 Aug 2014 11:57:47 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F0F1A0299 for ; Fri, 1 Aug 2014 11:57:47 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50458 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDI1M-0002X1-Ng; Fri, 01 Aug 2014 11:57:45 -0700 Message-ID: <53DBE325.1040505@usdonovans.com> Date: Fri, 01 Aug 2014 13:57:41 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com> In-Reply-To: <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JpMwiWjf3ya_PNZCJ3nL2v5JSYk Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:57:55 -0000 For host reports, the client would always use the identity in the=20 report, not the identity in the origin-host AVP. Steve On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: > I understood! But what will be the use of this info by the client? As f= or the client, the server is the identity of the Origin-host of the recei= ved answer. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > Lionel, > > The agent would not be inserting it's identity in the overload report. > The proposal is that the DOIC node that inserted the overload report > includes its diameter identity in the overload report. As such, it > would be the server's identity that is in the overload report. > > Sorry if I wasn't clear. > > Steve > > On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> So the topology hiding is not a relevant example here. Even with an id= entity inserted in the OLR, the client will never know to which server th= e request is sent because the only relevant info for the client is the Or= igin-host received in the answer i.e. the id of the agent. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) >> >> Lionel, >> >> The issue is that there could be multiple/many servers behind the agen= t >> that is changing the Origin-Host. If one of them is overloaded and >> generates a host report, clients will apply overload abatement to all >> requests sent through that agent. The end result would be that the no= n >> overloaded servers are under utilized. >> >> Steve >> >> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> Not sure to understand. If an agent inserts its identity as Origin-ho= st in answers forwarded from servers, the client will see the agent as th= e server. >>> What will be the added-value to add the identity of the server insert= ing the OLR if the client will store this information along the agent id?= >>> Sorry if I've missed something... >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>> Cc : dime@ietf.org >>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) >>> >>> Somewhat on on the path toward generalization, we have a second issue= >>> currently open that can be solved by having the DOIC node that insert= s >>> an overload report in an answer message include it's own diameter >>> identity in the overload report. >>> >>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-= Host. >>> >>> This issue points out that existing non DOIC agents are able to chang= e >>> the origin-host in answer messages. One example of where this is don= e >>> is in topology hiding implementations. >>> >>> This issue can be addressed through attribution of overload reports. >>> >>> As such, I propose that we add a required AVP to the OC-OLR group AVP= >>> that carries the diameter identity of the DOIC node that inserted the= >>> overload report into the answer message. Issue #66 points out the ne= ed >>> in host reports and issue #58 points out the need in realm reports. >>> >>> Steve >>> >>> >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>> >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote= : >>>> >>>>> I believe Nirav's view requires all hosts in a realm to be the same= vendor and use a proprietary communication protocol to synchronize the h= ost report. Or, if a multiple (redundant or active-active) load-balancing= agents are generating the report, they must similarly be synchronized. >>>>> >>>>> Is seems like including the host name per Ulrich's suggestion is a = simple way of avoiding proprietary mechanisms or coupling between hosts a= nd agents. >>>>> In some applications, the hosts can be completely decoupled (agnost= ic about each other). I think it would be poor to add a synchronization r= equirement just to support DOIC. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.moran= d@orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>> >>>>> Hi Steve, >>>>> >>>>> I agree with Nirav's view. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>> >>>>> Steve, >>>>> >>>>> For this issue, I don't agree to include identity of the DOIC node = that sends the report, into the realm reports. >>>>> >>>>> In my view, the issue mentioned below - of two agents not 100% sync= hronize w.r.t the realm-report - is the related to "how agents synchroniz= ed between themselves" and since that is not standardized we should not b= e developing protocol solution for the case which occurs due to this out-= of-standards solution. >>>>> >>>>> Besides, I don't see any issue due to slight miss-synchronization o= f the realm-reports between two agents since they should still represent = the realm load more or less accurately. >>>>> >>>>> Also if the agents are not synchronized and if they are playing the= role of DOIC reacting node then they will apply abatement algorithm base= d on different values (for the same realm). So it does not matter if the = client does the same. >>>>> >>>>> Finally, I don't see any value-add of using the "identity of the no= de that sends the realm-report" to discard the other report related to th= e same realm. In other words, this same logic can be achieved using seque= nce-numbers as well, i.e. when the overload-report of an realm is active,= the client is going to ignore all the reports of the same realm which ha= s lower sequence number value. So in essence, when two agents are sending= realm-reports, one of the reports is automatically ignored by the client= if their sequence numbers differ. So the outcome without including the "= identity if the node that sends realm report" is same as >>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will on= ly listen to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donova= n >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>> >>>>> All, >>>>> >>>>> Issue #58 deals with the fact that there can be multiple senders of= realm overload report for the same realm. >>>>> >>>>> Ulrich proposes one aspect of what is required in the issue descrip= tion: >>>>> >>>>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting nodes= may receive in different answer messages different realm-routed-request = type OLRs inserted by the different reporting nodes. Although it is expec= ted that the different reporting nodes report more or less the same conte= nt, it cannot be expected that reports are 100% synchronized. Especially = sequence numbers may differ. To allow reacting nodes correctly detect out= dates/replays/freshness of OLRs in this scenario, it is proposed that rea= lm-routed-request type OLRs are extended to contain the Diameter Identity= of the reporting node that inserted the realm-routed-request type OLR. (= e.g. as already proposed in draft-donovan-dime-agent-overload-01). Report= ing nodes that insert realm-routed-request type OLRs to answer messages M= UST also insert their Diameter Identity. Reacting nodes MUST take the Dia= meter Identity received within the OLR into account in order to detect ou= tdates/replays/freshness." >>>>> >>>>> I agree with Ulrich that realm reports must include the identity of= the DOIC node that sends the report. This would be an optional AVP only= required for realm reports. It would not be required for host reports a= s the identity of the sender of the host report is implicitly defined by = the origin-host in the answer message. >>>>> >>>>> I also agree that the Diameter Identity of the reporting node be us= ed to determine if a received report is ignored or used to update existin= g state. To this end I propose that we add wording that for the duration= of a realm report, the reacting node only listens for updates to the rea= lm report from from the DOIC node that sent the realm report that resulte= d in the realm OCS being stored. >>>>> >>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>>> >>>>> Steve >>>>> >>>>> >>>>> ___________________________________________________________________= ______________________________________________________ >>>>> >>>>> 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 a= vez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or privil= eged information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisatio= n. >>>>> 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 ha= ve been modified, changed or falsified. >>>>> Thank you. >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _____________________________________________________________________= ____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>> >>> >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d 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. >> >> > > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Fri Aug 1 12:02:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612371B289F for ; Fri, 1 Aug 2014 12:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBnQ8f0VRHUy for ; Fri, 1 Aug 2014 12:02:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE691A01C3 for ; Fri, 1 Aug 2014 12:02:50 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s71J2mhj012665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 14:02:49 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53DBBBBA.3060200@usdonovans.com> Date: Fri, 1 Aug 2014 14:02:48 -0500 X-Mao-Original-Outgoing-Id: 428612568.012439-e85dd3672c32f9185add1e1b047e8b1a Content-Transfer-Encoding: quoted-printable Message-Id: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EYAd55j2dt8n-HOtdkf38U6lW-s Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 19:02:53 -0000 I don't think you can conflate "host that generated this OLR" with "host = that is overloaded". It's perfectly valid for them to not be the same = thing, even for host reports. (But I'd be happy to include both.) On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: > Somewhat on on the path toward generalization, we have a second issue = currently open that can be solved by having the DOIC node that inserts = an overload report in an answer message include it's own diameter = identity in the overload report. >=20 > I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >=20 > This issue points out that existing non DOIC agents are able to change = the origin-host in answer messages. One example of where this is done = is in topology hiding implementations. >=20 > This issue can be addressed through attribution of overload reports. >=20 > As such, I propose that we add a required AVP to the OC-OLR group AVP = that carries the diameter identity of the DOIC node that inserted the = overload report into the answer message. Issue #66 points out the need = in host reports and issue #58 points out the need in realm reports. >=20 > Steve >=20 >=20 > On 8/1/14, 9:54 AM, Ben Campbell wrote: >> +1 (modulo my comment to generalize) >>=20 >> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>=20 >>> I believe Nirav=92s view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>> Is seems like including the host name per Ulrich=92s suggestion is = a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>> -Dave >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com >>> Sent: Friday, August 01, 2014 6:58 AM >>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>> Subject: Re: [Dime] DOIC issue #58 Proposal >>> Hi Steve, >>> I agree with Nirav's view. >>> Regards, >>> Lionel >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> Steve, >>> For this issue, I don=92t agree to include identity of the DOIC = node that sends the report, into the realm reports. >>> In my view, the issue mentioned below =96 of two agents not 100% = synchronize w.r.t the realm-report =96 is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>> Besides, I don=92t see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still = represent the realm load more or less accurately. >>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm = based on different values (for the same realm). So it does not matter if = the client does the same. >>> Finally, I don=92t see any value-add of using the "identity of the = node that sends the realm-report" to discard the other report related to = the same realm. In other words, this same logic can be achieved using = sequence-numbers as well, i.e. when the overload-report of an realm is = active, the client is going to ignore all the reports of the same realm = which has lower sequence number value. So in essence, when two agents = are sending realm-reports, one of the reports is automatically ignored = by the client if their sequence numbers differ. So the outcome without = including the "identity if the node that sends realm report" is same as >>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>> Regards, >>> Nirav. >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve = Donovan >>> Sent: Friday, August 01, 2014 1:23 AM >>> To: dime@ietf.org >>> Subject: [Dime] DOIC issue #58 Proposal >>> All, >>>=20 >>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>=20 >>> Ulrich proposes one aspect of what is required in the issue = description: >>>=20 >>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>=20 >>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports = as the identity of the sender of the host report is implicitly defined = by the origin-host in the answer message. >>>=20 >>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>=20 >>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>=20 >>> Steve >>>=20 >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>> 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. >>> _______________________________________________ >>> 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 nobody Fri Aug 1 12:53:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDFA1ABC74 for ; Fri, 1 Aug 2014 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iIm-IRnCIAB for ; Fri, 1 Aug 2014 12:53:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5EA1A0467 for ; Fri, 1 Aug 2014 12:53:54 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52177 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDIti-0006bH-8R; Fri, 01 Aug 2014 12:53:53 -0700 Message-ID: <53DBF04E.2050005@usdonovans.com> Date: Fri, 01 Aug 2014 14:53:50 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YBH7rpTYmkHmhr-9mwC_EfcXGQY Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 19:53:57 -0000 Yes, it could be either. The critical point is that the overloaded host = is indicated by the diameter id in the overload report, not the=20 origin-host AVP. Steve On 8/1/14, 2:02 PM, Ben Campbell wrote: > I don't think you can conflate "host that generated this OLR" with "hos= t that is overloaded". It's perfectly valid for them to not be the same t= hing, even for host reports. (But I'd be happy to include both.) > > On Aug 1, 2014, at 11:09 AM, Steve Donovan w= rote: > >> Somewhat on on the path toward generalization, we have a second issue = currently open that can be solved by having the DOIC node that inserts an= overload report in an answer message include it's own diameter identity = in the overload report. >> >> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >> >> This issue points out that existing non DOIC agents are able to change= the origin-host in answer messages. One example of where this is done i= s in topology hiding implementations. >> >> This issue can be addressed through attribution of overload reports. >> >> As such, I propose that we add a required AVP to the OC-OLR group AVP = that carries the diameter identity of the DOIC node that inserted the ove= rload report into the answer message. Issue #66 points out the need in h= ost reports and issue #58 points out the need in realm reports. >> >> Steve >> >> >> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>> +1 (modulo my comment to generalize) >>> >>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote:= >>> >>>> I believe Nirav=92s view requires all hosts in a realm to be the sam= e vendor and use a proprietary communication protocol to synchronize the = host report. Or, if a multiple (redundant or active-active) load-balancin= g agents are generating the report, they must similarly be synchronized. >>>> Is seems like including the host name per Ulrich=92s suggestion is= a simple way of avoiding proprietary mechanisms or coupling between host= s and agents. >>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization re= quirement just to support DOIC. >>>> -Dave >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.= morand@orange.com >>>> Sent: Friday, August 01, 2014 6:58 AM >>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>> Hi Steve, >>>> I agree with Nirav's view. >>>> Regards, >>>> Lionel >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> Steve, >>>> For this issue, I don=92t agree to include identity of the DOIC no= de that sends the report, into the realm reports. >>>> In my view, the issue mentioned below =96 of two agents not 100% s= ynchronize w.r.t the realm-report =96 is the related to "how agents synch= ronized between themselves" and since that is not standardized we should = not be developing protocol solution for the case which occurs due to this= out-of-standards solution. >>>> Besides, I don=92t see any issue due to slight miss-synchronizatio= n of the realm-reports between two agents since they should still represe= nt the realm load more or less accurately. >>>> Also if the agents are not synchronized and if they are playing th= e role of DOIC reacting node then they will apply abatement algorithm bas= ed on different values (for the same realm). So it does not matter if the= client does the same. >>>> Finally, I don=92t see any value-add of using the "identity of the= node that sends the realm-report" to discard the other report related to= the same realm. In other words, this same logic can be achieved using se= quence-numbers as well, i.e. when the overload-report of an realm is acti= ve, the client is going to ignore all the reports of the same realm which= has lower sequence number value. So in essence, when two agents are send= ing realm-reports, one of the reports is automatically ignored by the cli= ent if their sequence numbers differ. So the outcome without including th= e "identity if the node that sends realm report" is same as >>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>> Regards, >>>> Nirav. >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donov= an >>>> Sent: Friday, August 01, 2014 1:23 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] DOIC issue #58 Proposal >>>> All, >>>> >>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>> >>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>> >>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes = may receive in different answer messages different realm-routed-request t= ype OLRs inserted by the different reporting nodes. Although it is expect= ed that the different reporting nodes report more or less the same conten= t, it cannot be expected that reports are 100% synchronized. Especially s= equence numbers may differ. To allow reacting nodes correctly detect outd= ates/replays/freshness of OLRs in this scenario, it is proposed that real= m-routed-request type OLRs are extended to contain the Diameter Identity = of the reporting node that inserted the realm-routed-request type OLR. (e= =2Eg. as already proposed in draft-donovan-dime-agent-overload-01). Repor= ting nodes that insert realm-routed-request type OLRs to answer messages = MUST also insert their Diameter Identity. Reacting nodes MUST take the Di= ameter Identity received within the OLR into account in order to detect o= utdates/replays/freshness." >>>> >>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports as= the identity of the sender of the host report is implicitly defined by t= he origin-host in the answer message. >>>> >>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing= state. To this end I propose that we add wording that for the duration = of a realm report, the reacting node only listens for updates to the real= m report from from the DOIC node that sent the realm report that resulted= in the realm OCS being stored. >>>> >>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>> >>>> Steve >>>> >>>> >>>> ____________________________________________________________________= _____________________________________________________ >>>> 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 av= ez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>> This message and its attachments may contain confidential or privi= leged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation= =2E >>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>> Thank you. >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Aug 1 13:27:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086E31B28CE for ; Fri, 1 Aug 2014 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBWsg7lh9Xaf for ; Fri, 1 Aug 2014 13:27:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABFD1A0137 for ; Fri, 1 Aug 2014 13:27:45 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 63CA426486D; Fri, 1 Aug 2014 22:27:43 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4776727C053; Fri, 1 Aug 2014 22:27:43 +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.03.0181.006; Fri, 1 Aug 2014 22:27:42 +0200 From: To: Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u768Zg///5KYCAACW8wP//5a4AgAAl0h7//+H4gAAHVdJx Date: Fri, 1 Aug 2014 20:27:42 +0000 Message-ID: <8411_1406924863_53DBF83F_8411_14541_1_h2x7o315dli0e62si6123wdh.1406924859433@email.android.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> In-Reply-To: <53DBE325.1040505@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.154818 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/80ybphi29fzGhhEYLWJivN_zR4Y Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 20:27:50 -0000 The question is: how does the client know to which the current request will= be sent? As far as I know, the Origin-host is used as identification of th= e server assigned to the user. So how will the client interpret the I'd int= o the OLR? Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- For host reports, the client would always use the identity in the report, not the identity in the origin-host AVP. Steve On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: > I understood! But what will be the use of this info by the client? As for= the client, the server is the identity of the Origin-host of the received = answer. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > Lionel, > > The agent would not be inserting it's identity in the overload report. > The proposal is that the DOIC node that inserted the overload report > includes its diameter identity in the overload report. As such, it > would be the server's identity that is in the overload report. > > Sorry if I wasn't clear. > > Steve > > On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> So the topology hiding is not a relevant example here. Even with an iden= tity inserted in the OLR, the client will never know to which server the re= quest is sent because the only relevant info for the client is the Origin-h= ost received in the answer i.e. the id of the agent. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #= 58 Proposal) >> >> Lionel, >> >> The issue is that there could be multiple/many servers behind the agent >> that is changing the Origin-Host. If one of them is overloaded and >> generates a host report, clients will apply overload abatement to all >> requests sent through that agent. The end result would be that the non >> overloaded servers are under utilized. >> >> Steve >> >> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> Not sure to understand. If an agent inserts its identity as Origin-host= in answers forwarded from servers, the client will see the agent as the se= rver. >>> What will be the added-value to add the identity of the server insertin= g the OLR if the client will store this information along the agent id? >>> Sorry if I've missed something... >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>> Cc : dime@ietf.org >>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 = Proposal) >>> >>> Somewhat on on the path toward generalization, we have a second issue >>> currently open that can be solved by having the DOIC node that inserts >>> an overload report in an answer message include it's own diameter >>> identity in the overload report. >>> >>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Ho= st. >>> >>> This issue points out that existing non DOIC agents are able to change >>> the origin-host in answer messages. One example of where this is done >>> is in topology hiding implementations. >>> >>> This issue can be addressed through attribution of overload reports. >>> >>> As such, I propose that we add a required AVP to the OC-OLR group AVP >>> that carries the diameter identity of the DOIC node that inserted the >>> overload report into the answer message. Issue #66 points out the need >>> in host reports and issue #58 points out the need in realm reports. >>> >>> Steve >>> >>> >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>> >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>> >>>>> I believe Nirav's view requires all hosts in a realm to be the same v= endor and use a proprietary communication protocol to synchronize the host = report. Or, if a multiple (redundant or active-active) load-balancing agent= s are generating the report, they must similarly be synchronized. >>>>> >>>>> Is seems like including the host name per Ulrich's suggestion is a si= mple way of avoiding proprietary mechanisms or coupling between hosts and a= gents. >>>>> In some applications, the hosts can be completely decoupled (agnostic= about each other). I think it would be poor to add a synchronization requi= rement just to support DOIC. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@= orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>> >>>>> Hi Steve, >>>>> >>>>> I agree with Nirav's view. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>> >>>>> Steve, >>>>> >>>>> For this issue, I don't agree to include identity of the DOIC node th= at sends the report, into the realm reports. >>>>> >>>>> In my view, the issue mentioned below - of two agents not 100% synchr= onize w.r.t the realm-report - is the related to "how agents synchronized b= etween themselves" and since that is not standardized we should not be deve= loping protocol solution for the case which occurs due to this out-of-stand= ards solution. >>>>> >>>>> Besides, I don't see any issue due to slight miss-synchronization of = the realm-reports between two agents since they should still represent the = realm load more or less accurately. >>>>> >>>>> Also if the agents are not synchronized and if they are playing the r= ole of DOIC reacting node then they will apply abatement algorithm based on= different values (for the same realm). So it does not matter if the client= does the same. >>>>> >>>>> Finally, I don't see any value-add of using the "identity of the node= that sends the realm-report" to discard the other report related to the sa= me realm. In other words, this same logic can be achieved using sequence-nu= mbers as well, i.e. when the overload-report of an realm is active, the cli= ent is going to ignore all the reports of the same realm which has lower se= quence number value. So in essence, when two agents are sending realm-repor= ts, one of the reports is automatically ignored by the client if their sequ= ence numbers differ. So the outcome without including the "identity if the = node that sends realm report" is same as >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>> >>>>> All, >>>>> >>>>> Issue #58 deals with the fact that there can be multiple senders of r= ealm overload report for the same realm. >>>>> >>>>> Ulrich proposes one aspect of what is required in the issue descripti= on: >>>>> >>>>> "In deployments where more than one node is configured to take the ro= le of a reporting node for realm-routed-request reports, reacting nodes may= receive in different answer messages different realm-routed-request type O= LRs inserted by the different reporting nodes. Although it is expected that= the different reporting nodes report more or less the same content, it can= not be expected that reports are 100% synchronized. Especially sequence num= bers may differ. To allow reacting nodes correctly detect outdates/replays/= freshness of OLRs in this scenario, it is proposed that realm-routed-reques= t type OLRs are extended to contain the Diameter Identity of the reporting = node that inserted the realm-routed-request type OLR. (e.g. as already prop= osed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their Di= ameter Identity. Reacting nodes MUST take the Diameter Identity received wi= thin the OLR into account in order to detect outdates/replays/freshness." >>>>> >>>>> I agree with Ulrich that realm reports must include the identity of t= he DOIC node that sends the report. This would be an optional AVP only req= uired for realm reports. It would not be required for host reports as the = identity of the sender of the host report is implicitly defined by the orig= in-host in the answer message. >>>>> >>>>> I also agree that the Diameter Identity of the reporting node be used= to determine if a received report is ignored or used to update existing st= ate. To this end I propose that we add wording that for the duration of a = realm report, the reacting node only listens for updates to the realm repor= t from from the DOIC node that sent the realm report that resulted in the r= ealm OCS being stored. >>>>> >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>>> >>>>> Steve >>>>> >>>>> >>>>> _____________________________________________________________________= ____________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________________________________= __________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 13:39:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8141D1A006C for ; Fri, 1 Aug 2014 13:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVh5y1UIUUzR for ; Fri, 1 Aug 2014 13:39:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4461F1A0030 for ; Fri, 1 Aug 2014 13:39:40 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s71Kdb0a020403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 15:39:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53DBF04E.2050005@usdonovans.com> Date: Fri, 1 Aug 2014 15:39:37 -0500 X-Mao-Original-Outgoing-Id: 428618377.488599-0412e474c20fa7e6d6d745c6e79e7a17 Content-Transfer-Encoding: quoted-printable Message-Id: <1D8A6E84-686F-4F55-8680-05103292BC1E@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YdiDvyXZHDxPXsewTwtPEOt1ruI Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 20:39:43 -0000 On Aug 1, 2014, at 2:53 PM, Steve Donovan = wrote: > Yes, it could be either. The critical point is that the overloaded = host is indicated by the diameter id in the overload report, not the = origin-host AVP. >=20 Right. My point was solving the "did this new OLR come from the same = source as the previous one" problem and the "someone messed with = Origin-Host so that I think the wrong thing is overloaded" are separate = problems, with separate (but similar) solutions. Both could occur at the = same time, with the same OLR. > Steve >=20 > On 8/1/14, 2:02 PM, Ben Campbell wrote: >> I don't think you can conflate "host that generated this OLR" with = "host that is overloaded". It's perfectly valid for them to not be the = same thing, even for host reports. (But I'd be happy to include both.) >>=20 >> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>=20 >>> Somewhat on on the path toward generalization, we have a second = issue currently open that can be solved by having the DOIC node that = inserts an overload report in an answer message include it's own = diameter identity in the overload report. >>>=20 >>> I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >>>=20 >>> This issue points out that existing non DOIC agents are able to = change the origin-host in answer messages. One example of where this is = done is in topology hiding implementations. >>>=20 >>> This issue can be addressed through attribution of overload reports. >>>=20 >>> As such, I propose that we add a required AVP to the OC-OLR group = AVP that carries the diameter identity of the DOIC node that inserted = the overload report into the answer message. Issue #66 points out the = need in host reports and issue #58 points out the need in realm reports. >>>=20 >>> Steve >>>=20 >>>=20 >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>>=20 >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson = wrote: >>>>=20 >>>>> I believe Nirav=92s view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>>>> Is seems like including the host name per Ulrich=92s suggestion = is a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>>>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>>>> -Dave >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>> Hi Steve, >>>>> I agree with Nirav's view. >>>>> Regards, >>>>> Lionel >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>> Steve, >>>>> For this issue, I don=92t agree to include identity of the DOIC = node that sends the report, into the realm reports. >>>>> In my view, the issue mentioned below =96 of two agents not 100% = synchronize w.r.t the realm-report =96 is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>>>> Besides, I don=92t see any issue due to slight = miss-synchronization of the realm-reports between two agents since they = should still represent the realm load more or less accurately. >>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm = based on different values (for the same realm). So it does not matter if = the client does the same. >>>>> Finally, I don=92t see any value-add of using the "identity of = the node that sends the realm-report" to discard the other report = related to the same realm. In other words, this same logic can be = achieved using sequence-numbers as well, i.e. when the overload-report = of an realm is active, the client is going to ignore all the reports of = the same realm which has lower sequence number value. So in essence, = when two agents are sending realm-reports, one of the reports is = automatically ignored by the client if their sequence numbers differ. So = the outcome without including the "identity if the node that sends realm = report" is same as >>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve = Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>> All, >>>>>=20 >>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>=20 >>>>> Ulrich proposes one aspect of what is required in the issue = description: >>>>>=20 >>>>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>=20 >>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP = only required for realm reports. It would not be required for host = reports as the identity of the sender of the host report is implicitly = defined by the origin-host in the answer message. >>>>>=20 >>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>>>=20 >>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>=20 >>>>> Steve >>>>>=20 >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des = informations confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>> 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. >>>>> _______________________________________________ >>>>> 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 nobody Fri Aug 1 14:07:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5675E1A00DE for ; Fri, 1 Aug 2014 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-hnHpT-vUWo for ; Fri, 1 Aug 2014 14:07:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353611A008B for ; Fri, 1 Aug 2014 14:07:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7B5BE22CF5A; Fri, 1 Aug 2014 23:07:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5F3F3238055; Fri, 1 Aug 2014 23:07:45 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 23:07:45 +0200 From: To: Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u768Zg///5KYCAACW8wP//5a4AgAAl0h7//+H4gAAIu7lA Date: Fri, 1 Aug 2014 21:07:44 +0000 Message-ID: <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> In-Reply-To: <53DBE325.1040505@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.154818 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lnOlOpe-7tDN3UyjOZNPiBkebyw Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 21:07:51 -0000 But the client will never use the identity received in the OLR to check whi= ch abatement to apply when sending a request to the server... that is the a= gent from its point of view. Therefore the client will never apply the overload abatement. Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- For host reports, the client would always use the identity in the report, not the identity in the origin-host AVP. Steve On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: > I understood! But what will be the use of this info by the client? As for= the client, the server is the identity of the Origin-host of the received = answer. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > Lionel, > > The agent would not be inserting it's identity in the overload report. > The proposal is that the DOIC node that inserted the overload report > includes its diameter identity in the overload report. As such, it > would be the server's identity that is in the overload report. > > Sorry if I wasn't clear. > > Steve > > On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> So the topology hiding is not a relevant example here. Even with an iden= tity inserted in the OLR, the client will never know to which server the re= quest is sent because the only relevant info for the client is the Origin-h= ost received in the answer i.e. the id of the agent. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #= 58 Proposal) >> >> Lionel, >> >> The issue is that there could be multiple/many servers behind the agent >> that is changing the Origin-Host. If one of them is overloaded and >> generates a host report, clients will apply overload abatement to all >> requests sent through that agent. The end result would be that the non >> overloaded servers are under utilized. >> >> Steve >> >> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> Not sure to understand. If an agent inserts its identity as Origin-host= in answers forwarded from servers, the client will see the agent as the se= rver. >>> What will be the added-value to add the identity of the server insertin= g the OLR if the client will store this information along the agent id? >>> Sorry if I've missed something... >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>> Cc : dime@ietf.org >>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 = Proposal) >>> >>> Somewhat on on the path toward generalization, we have a second issue >>> currently open that can be solved by having the DOIC node that inserts >>> an overload report in an answer message include it's own diameter >>> identity in the overload report. >>> >>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Ho= st. >>> >>> This issue points out that existing non DOIC agents are able to change >>> the origin-host in answer messages. One example of where this is done >>> is in topology hiding implementations. >>> >>> This issue can be addressed through attribution of overload reports. >>> >>> As such, I propose that we add a required AVP to the OC-OLR group AVP >>> that carries the diameter identity of the DOIC node that inserted the >>> overload report into the answer message. Issue #66 points out the need >>> in host reports and issue #58 points out the need in realm reports. >>> >>> Steve >>> >>> >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>> >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>> >>>>> I believe Nirav's view requires all hosts in a realm to be the same v= endor and use a proprietary communication protocol to synchronize the host = report. Or, if a multiple (redundant or active-active) load-balancing agent= s are generating the report, they must similarly be synchronized. >>>>> >>>>> Is seems like including the host name per Ulrich's suggestion is a si= mple way of avoiding proprietary mechanisms or coupling between hosts and a= gents. >>>>> In some applications, the hosts can be completely decoupled (agnostic= about each other). I think it would be poor to add a synchronization requi= rement just to support DOIC. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@= orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>> >>>>> Hi Steve, >>>>> >>>>> I agree with Nirav's view. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>> >>>>> Steve, >>>>> >>>>> For this issue, I don't agree to include identity of the DOIC node th= at sends the report, into the realm reports. >>>>> >>>>> In my view, the issue mentioned below - of two agents not 100% synchr= onize w.r.t the realm-report - is the related to "how agents synchronized b= etween themselves" and since that is not standardized we should not be deve= loping protocol solution for the case which occurs due to this out-of-stand= ards solution. >>>>> >>>>> Besides, I don't see any issue due to slight miss-synchronization of = the realm-reports between two agents since they should still represent the = realm load more or less accurately. >>>>> >>>>> Also if the agents are not synchronized and if they are playing the r= ole of DOIC reacting node then they will apply abatement algorithm based on= different values (for the same realm). So it does not matter if the client= does the same. >>>>> >>>>> Finally, I don't see any value-add of using the "identity of the node= that sends the realm-report" to discard the other report related to the sa= me realm. In other words, this same logic can be achieved using sequence-nu= mbers as well, i.e. when the overload-report of an realm is active, the cli= ent is going to ignore all the reports of the same realm which has lower se= quence number value. So in essence, when two agents are sending realm-repor= ts, one of the reports is automatically ignored by the client if their sequ= ence numbers differ. So the outcome without including the "identity if the = node that sends realm report" is same as >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>> >>>>> All, >>>>> >>>>> Issue #58 deals with the fact that there can be multiple senders of r= ealm overload report for the same realm. >>>>> >>>>> Ulrich proposes one aspect of what is required in the issue descripti= on: >>>>> >>>>> "In deployments where more than one node is configured to take the ro= le of a reporting node for realm-routed-request reports, reacting nodes may= receive in different answer messages different realm-routed-request type O= LRs inserted by the different reporting nodes. Although it is expected that= the different reporting nodes report more or less the same content, it can= not be expected that reports are 100% synchronized. Especially sequence num= bers may differ. To allow reacting nodes correctly detect outdates/replays/= freshness of OLRs in this scenario, it is proposed that realm-routed-reques= t type OLRs are extended to contain the Diameter Identity of the reporting = node that inserted the realm-routed-request type OLR. (e.g. as already prop= osed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their Di= ameter Identity. Reacting nodes MUST take the Diameter Identity received wi= thin the OLR into account in order to detect outdates/replays/freshness." >>>>> >>>>> I agree with Ulrich that realm reports must include the identity of t= he DOIC node that sends the report. This would be an optional AVP only req= uired for realm reports. It would not be required for host reports as the = identity of the sender of the host report is implicitly defined by the orig= in-host in the answer message. >>>>> >>>>> I also agree that the Diameter Identity of the reporting node be used= to determine if a received report is ignored or used to update existing st= ate. To this end I propose that we add wording that for the duration of a = realm report, the reacting node only listens for updates to the realm repor= t from from the DOIC node that sent the realm report that resulted in the r= ealm OCS being stored. >>>>> >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>>> >>>>> Steve >>>>> >>>>> >>>>> _____________________________________________________________________= ____________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________________________________= __________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 15:04:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551A91A014C for ; Fri, 1 Aug 2014 15:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PV50vmWLqxG for ; Fri, 1 Aug 2014 15:04:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D8E1A013B for ; Fri, 1 Aug 2014 15:04:51 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53401 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDKwQ-0007WF-3x; Fri, 01 Aug 2014 15:04:49 -0700 Message-ID: <53DC0EFE.9020601@usdonovans.com> Date: Fri, 01 Aug 2014 17:04:46 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com> In-Reply-To: <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iNQxhTf8udxG-TYLPEX-5mzZjSA Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 22:04:54 -0000 True. So the question is, for this scenario, is it better for the client to=20 ignore the overload report - as determined by there being a difference=20 in the identity in the overload report and the identity in the=20 origin-host AVP - or for the client to apply the overload report to all=20 traffic sent through the agent? If we choose the latter then what happens when the client starts seeing=20 overload reports from multiple servers behind the agent? My instinct is that it is better for the client to ignore the report as=20 not doing so could result in a significant reduction in overall traffic=20 sent through the non DOIC, origin-host munging agent. Steve On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: > But the client will never use the identity received in the OLR to check= which abatement to apply when sending a request to the server... that is= the agent from its point of view. > Therefore the client will never apply the overload abatement. > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > For host reports, the client would always use the identity in the > report, not the identity in the origin-host AVP. > > Steve > > On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >> I understood! But what will be the use of this info by the client? As = for the client, the server is the identity of the Origin-host of the rece= ived answer. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Steve Donovan a =E9crit ---- >> >> >> Lionel, >> >> The agent would not be inserting it's identity in the overload report.= >> The proposal is that the DOIC node that inserted the overload report >> includes its diameter identity in the overload report. As such, it >> would be the server's identity that is in the overload report. >> >> Sorry if I wasn't clear. >> >> Steve >> >> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> So the topology hiding is not a relevant example here. Even with an i= dentity inserted in the OLR, the client will never know to which server t= he request is sent because the only relevant info for the client is the O= rigin-host received in the answer i.e. the id of the agent. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >>> =C0 : MORAND Lionel IMT/OLN >>> Cc : dime@ietf.org >>> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issu= e #58 Proposal) >>> >>> Lionel, >>> >>> The issue is that there could be multiple/many servers behind the age= nt >>> that is changing the Origin-Host. If one of them is overloaded and >>> generates a host report, clients will apply overload abatement to all= >>> requests sent through that agent. The end result would be that the n= on >>> overloaded servers are under utilized. >>> >>> Steve >>> >>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> Not sure to understand. If an agent inserts its identity as Origin-h= ost in answers forwarded from servers, the client will see the agent as t= he server. >>>> What will be the added-value to add the identity of the server inser= ting the OLR if the client will store this information along the agent id= ? >>>> Sorry if I've missed something... >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan= >>>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>>> Cc : dime@ietf.org >>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #= 58 Proposal) >>>> >>>> Somewhat on on the path toward generalization, we have a second issu= e >>>> currently open that can be solved by having the DOIC node that inser= ts >>>> an overload report in an answer message include it's own diameter >>>> identity in the overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin= -Host. >>>> >>>> This issue points out that existing non DOIC agents are able to chan= ge >>>> the origin-host in answer messages. One example of where this is do= ne >>>> is in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports.= >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group AV= P >>>> that carries the diameter identity of the DOIC node that inserted th= e >>>> overload report into the answer message. Issue #66 points out the n= eed >>>> in host reports and issue #58 points out the need in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrot= e: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the sam= e vendor and use a proprietary communication protocol to synchronize the = host report. Or, if a multiple (redundant or active-active) load-balancin= g agents are generating the report, they must similarly be synchronized. >>>>>> >>>>>> Is seems like including the host name per Ulrich's suggestion is a= simple way of avoiding proprietary mechanisms or coupling between hosts = and agents. >>>>>> In some applications, the hosts can be completely decoupled (agnos= tic about each other). I think it would be poor to add a synchronization = requirement just to support DOIC. >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.mora= nd@orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>> >>>>>> Hi Steve, >>>>>> >>>>>> I agree with Nirav's view. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Lionel >>>>>> >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>> >>>>>> Steve, >>>>>> >>>>>> For this issue, I don't agree to include identity of the DOIC node= that sends the report, into the realm reports. >>>>>> >>>>>> In my view, the issue mentioned below - of two agents not 100% syn= chronize w.r.t the realm-report - is the related to "how agents synchroni= zed between themselves" and since that is not standardized we should not = be developing protocol solution for the case which occurs due to this out= -of-standards solution. >>>>>> >>>>>> Besides, I don't see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still represent= the realm load more or less accurately. >>>>>> >>>>>> Also if the agents are not synchronized and if they are playing th= e role of DOIC reacting node then they will apply abatement algorithm bas= ed on different values (for the same realm). So it does not matter if the= client does the same. >>>>>> >>>>>> Finally, I don't see any value-add of using the "identity of the n= ode that sends the realm-report" to discard the other report related to t= he same realm. In other words, this same logic can be achieved using sequ= ence-numbers as well, i.e. when the overload-report of an realm is active= , the client is going to ignore all the reports of the same realm which h= as lower sequence number value. So in essence, when two agents are sendin= g realm-reports, one of the reports is automatically ignored by the clien= t if their sequence numbers differ. So the outcome without including the = "identity if the node that sends realm report" is same as >>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will o= nly listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donov= an >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>> >>>>>> All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders o= f realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descri= ption: >>>>>> >>>>>> "In deployments where more than one node is configured to take the= role of a reporting node for realm-routed-request reports, reacting node= s may receive in different answer messages different realm-routed-request= type OLRs inserted by the different reporting nodes. Although it is expe= cted that the different reporting nodes report more or less the same cont= ent, it cannot be expected that reports are 100% synchronized. Especially= sequence numbers may differ. To allow reacting nodes correctly detect ou= tdates/replays/freshness of OLRs in this scenario, it is proposed that re= alm-routed-request type OLRs are extended to contain the Diameter Identit= y of the reporting node that inserted the realm-routed-request type OLR. = (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Repor= ting nodes that insert realm-routed-request type OLRs to answer messages = MUST also insert their Diameter Identity. Reacting nodes MUST take the Di= ameter Identity received within the OLR into account in order to detect o= utdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity o= f the DOIC node that sends the report. This would be an optional AVP onl= y required for realm reports. It would not be required for host reports = as the identity of the sender of the host report is implicitly defined by= the origin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be u= sed to determine if a received report is ignored or used to update existi= ng state. To this end I propose that we add wording that for the duratio= n of a realm report, the reacting node only listens for updates to the re= alm report from from the DOIC node that sent the realm report that result= ed in the realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will on= ly listen to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> __________________________________________________________________= _______________________________________________________ >>>>>> >>>>>> 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 me= ssages electroniques etant susceptibles d'alteration, >>>>>> Orange decline toute responsabilite si ce message a ete altere, de= forme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or privi= leged information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisati= on. >>>>>> 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 h= ave been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> ____________________________________________________________________= _____________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations c= onfidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privile= ged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation= =2E >>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>> Thank you. >>>> >>>> >>> _____________________________________________________________________= ____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>> >>> >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d 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. >> >> > > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Fri Aug 1 18:37:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6292D1A02F8 for ; Fri, 1 Aug 2014 18:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM3gpjv8nqxC for ; Fri, 1 Aug 2014 18:37:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A851A02EA for ; Fri, 1 Aug 2014 18:37:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5CBA122CFD3; Sat, 2 Aug 2014 03:37:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 41E25238055; Sat, 2 Aug 2014 03:37:39 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Sat, 2 Aug 2014 03:37:39 +0200 From: To: Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u768Zg///5KYCAACW8wP//5a4AgAAl0h7//+H4gAAIu7lA///uZwCAAF0BmA== Date: Sat, 2 Aug 2014 01:37:37 +0000 Message-ID: <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> In-Reply-To: <53DC0EFE.9020601@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.154818 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PhAlkkiZfy-OzIiO_0jCe6etU3U Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2014 01:37:46 -0000 In this scenario and other similar scenari, my requirement will be to remov= e any host-based report and forward only realm-based reports. Any host-base= d would be useless for clients beyond the agent. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- True. So the question is, for this scenario, is it better for the client to ignore the overload report - as determined by there being a difference in the identity in the overload report and the identity in the origin-host AVP - or for the client to apply the overload report to all traffic sent through the agent? If we choose the latter then what happens when the client starts seeing overload reports from multiple servers behind the agent? My instinct is that it is better for the client to ignore the report as not doing so could result in a significant reduction in overall traffic sent through the non DOIC, origin-host munging agent. Steve On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: > But the client will never use the identity received in the OLR to check w= hich abatement to apply when sending a request to the server... that is the= agent from its point of view. > Therefore the client will never apply the overload abatement. > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > For host reports, the client would always use the identity in the > report, not the identity in the origin-host AVP. > > Steve > > On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >> I understood! But what will be the use of this info by the client? As fo= r the client, the server is the identity of the Origin-host of the received= answer. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Steve Donovan a =E9crit ---- >> >> >> Lionel, >> >> The agent would not be inserting it's identity in the overload report. >> The proposal is that the DOIC node that inserted the overload report >> includes its diameter identity in the overload report. As such, it >> would be the server's identity that is in the overload report. >> >> Sorry if I wasn't clear. >> >> Steve >> >> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> So the topology hiding is not a relevant example here. Even with an ide= ntity inserted in the OLR, the client will never know to which server the r= equest is sent because the only relevant info for the client is the Origin-= host received in the answer i.e. the id of the agent. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >>> =C0 : MORAND Lionel IMT/OLN >>> Cc : dime@ietf.org >>> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) >>> >>> Lionel, >>> >>> The issue is that there could be multiple/many servers behind the agent >>> that is changing the Origin-Host. If one of them is overloaded and >>> generates a host report, clients will apply overload abatement to all >>> requests sent through that agent. The end result would be that the non >>> overloaded servers are under utilized. >>> >>> Steve >>> >>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> Not sure to understand. If an agent inserts its identity as Origin-hos= t in answers forwarded from servers, the client will see the agent as the s= erver. >>>> What will be the added-value to add the identity of the server inserti= ng the OLR if the client will store this information along the agent id? >>>> Sorry if I've missed something... >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>>> Cc : dime@ietf.org >>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) >>>> >>>> Somewhat on on the path toward generalization, we have a second issue >>>> currently open that can be solved by having the DOIC node that inserts >>>> an overload report in an answer message include it's own diameter >>>> identity in the overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >>>> >>>> This issue points out that existing non DOIC agents are able to change >>>> the origin-host in answer messages. One example of where this is done >>>> is in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports. >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group AVP >>>> that carries the diameter identity of the DOIC node that inserted the >>>> overload report into the answer message. Issue #66 points out the need >>>> in host reports and issue #58 points out the need in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the host= report. Or, if a multiple (redundant or active-active) load-balancing agen= ts are generating the report, they must similarly be synchronized. >>>>>> >>>>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization requ= irement just to support DOIC. >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand= @orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>> >>>>>> Hi Steve, >>>>>> >>>>>> I agree with Nirav's view. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Lionel >>>>>> >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>> >>>>>> Steve, >>>>>> >>>>>> For this issue, I don't agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >>>>>> >>>>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>>>> >>>>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>>>> >>>>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>>>> >>>>>> Finally, I don't see any value-add of using the "identity of the nod= e that sends the realm-report" to discard the other report related to the s= ame realm. In other words, this same logic can be achieved using sequence-n= umbers as well, i.e. when the overload-report of an realm is active, the cl= ient is going to ignore all the reports of the same realm which has lower s= equence number value. So in essence, when two agents are sending realm-repo= rts, one of the reports is automatically ignored by the client if their seq= uence numbers differ. So the outcome without including the "identity if the= node that sends realm report" is same as >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>> >>>>>> All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>>>> >>>>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes ma= y receive in different answer messages different realm-routed-request type = OLRs inserted by the different reporting nodes. Although it is expected tha= t the different reporting nodes report more or less the same content, it ca= nnot be expected that reports are 100% synchronized. Especially sequence nu= mbers may differ. To allow reacting nodes correctly detect outdates/replays= /freshness of OLRs in this scenario, it is proposed that realm-routed-reque= st type OLRs are extended to contain the Diameter Identity of the reporting= node that inserted the realm-routed-request type OLR. (e.g. as already pro= posed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert= realm-routed-request type OLRs to answer messages MUST also insert their D= iameter Identity. Reacting nodes MUST take the Diameter Identity received w= ithin the OLR into account in order to detect outdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only re= quired for realm reports. It would not be required for host reports as the= identity of the sender of the host report is implicitly defined by the ori= gin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing s= tate. To this end I propose that we add wording that for the duration of a= realm report, the reacting node only listens for updates to the realm repo= rt from from the DOIC node that sent the realm report that resulted in the = realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> ____________________________________________________________________= _____________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations c= onfidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>>>> Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or privile= ged 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> ______________________________________________________________________= ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privilege= d 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. >>>> >>>> >>> _______________________________________________________________________= __________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Aug 1 20:37:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F7C1A0387 for ; Fri, 1 Aug 2014 20:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dr_5V-AMJoX for ; Fri, 1 Aug 2014 20:37:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA6A1A01FA for ; Fri, 1 Aug 2014 20:37:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU61136; Sat, 02 Aug 2014 03:37:40 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 2 Aug 2014 04:37:39 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Sat, 2 Aug 2014 11:37:27 +0800 From: "Shishufeng (Susan)" To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPrccW68dF5OCezEe+7yNvYXl1rJu8qNhg Date: Sat, 2 Aug 2014 03:37:26 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> In-Reply-To: <53DBF04E.2050005@usdonovans.com> Accept-Language: en-GB, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NyAGU_JGyQaG5of_Dty5hZ6bwSM Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2014 03:37:47 -0000 Hello, I really don't understand the logic for the host to insert its own identity= into the overload report. Wouldn't it be the host to report its own overlo= ad report in an answer message to the client? Why we need the agent to do a= nything in this case? To say the least, if the host can insert its identity into the message, wha= t's the benefit to have the agent for topology hiding? Best Regards, Susan -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Saturday, August 02, 2014 3:54 AM To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Yes, it could be either. The critical point is that the overloaded host is= indicated by the diameter id in the overload report, not the origin-host A= VP. Steve On 8/1/14, 2:02 PM, Ben Campbell wrote: > I don't think you can conflate "host that generated this OLR" with=20 > "host that is overloaded". It's perfectly valid for them to not be the=20 > same thing, even for host reports. (But I'd be happy to include=20 > both.) > > On Aug 1, 2014, at 11:09 AM, Steve Donovan wro= te: > >> Somewhat on on the path toward generalization, we have a second issue cu= rrently open that can be solved by having the DOIC node that inserts an ove= rload report in an answer message include it's own diameter identity in the= overload report. >> >> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Hos= t. >> >> This issue points out that existing non DOIC agents are able to change t= he origin-host in answer messages. One example of where this is done is in= topology hiding implementations. >> >> This issue can be addressed through attribution of overload reports. >> >> As such, I propose that we add a required AVP to the OC-OLR group AVP th= at carries the diameter identity of the DOIC node that inserted the overloa= d report into the answer message. Issue #66 points out the need in host re= ports and issue #58 points out the need in realm reports. >> >> Steve >> >> >> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>> +1 (modulo my comment to generalize) >>> >>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>> >>>> I believe Nirav's view requires all hosts in a realm to be the same ve= ndor and use a proprietary communication protocol to synchronize the host r= eport. Or, if a multiple (redundant or active-active) load-balancing agents= are generating the report, they must similarly be synchronized. >>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>> In some applications, the hosts can be completely decoupled (agnostic = about each other). I think it would be poor to add a synchronization requir= ement just to support DOIC. >>>> -Dave >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>> lionel.morand@orange.com >>>> Sent: Friday, August 01, 2014 6:58 AM >>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>> Hi Steve, >>>> I agree with Nirav's view. >>>> Regards, >>>> Lionel >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> Steve, >>>> For this issue, I don't agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>> Finally, I don't see any value-add of using the "identity of the=20 >>>> node that sends the realm-report" to discard the other report=20 >>>> related to the same realm. In other words, this same logic can be=20 >>>> achieved using sequence-numbers as well, i.e. when the=20 >>>> overload-report of an realm is active, the client is going to=20 >>>> ignore all the reports of the same realm which has lower sequence=20 >>>> number value. So in essence, when two agents are sending=20 >>>> realm-reports, one of the reports is automatically ignored by the=20 >>>> client if their sequence numbers differ. So the outcome without=20 >>>> including the "identity if the node that sends realm report" is=20 >>>> same as >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>> Regards, >>>> Nirav. >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>> Donovan >>>> Sent: Friday, August 01, 2014 1:23 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] DOIC issue #58 Proposal >>>> All, >>>> >>>> Issue #58 deals with the fact that there can be multiple senders of re= alm overload report for the same realm. >>>> >>>> Ulrich proposes one aspect of what is required in the issue descriptio= n: >>>> >>>> "In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that = the different reporting nodes report more or less the same content, it cann= ot be expected that reports are 100% synchronized. Especially sequence numb= ers may differ. To allow reacting nodes correctly detect outdates/replays/f= reshness of OLRs in this scenario, it is proposed that realm-routed-request= type OLRs are extended to contain the Diameter Identity of the reporting n= ode that inserted the realm-routed-request type OLR. (e.g. as already propo= sed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert r= ealm-routed-request type OLRs to answer messages MUST also insert their Dia= meter Identity. Reacting nodes MUST take the Diameter Identity received wit= hin the OLR into account in order to detect outdates/replays/freshness." >>>> >>>> I agree with Ulrich that realm reports must include the identity of th= e DOIC node that sends the report. This would be an optional AVP only requ= ired for realm reports. It would not be required for host reports as the i= dentity of the sender of the host report is implicitly defined by the origi= n-host in the answer message. >>>> >>>> I also agree that the Diameter Identity of the reporting node be used = to determine if a received report is ignored or used to update existing sta= te. To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report= from from the DOIC node that sent the realm report that resulted in the re= alm OCS being stored. >>>> >>>> The effect should be that the reacting node will accept a realm report= from anyone when there is no active OLR for the realm but it will only lis= ten to one reporting node when it has an active report. >>>> >>>> Steve >>>> >>>> >>>> ______________________________________________________________________= ___________________________________________________ >>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>> informations confidentielles ou privilegiees et ne doivent donc pas=20 >>>> etre diffuses, exploites ou copies sans autorisation. Si vous avez=20 >>>> recu ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant sus= ceptibles 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=20 >>>> privileged information that may be protected by law; they should not b= e 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. >>>> _______________________________________________ >>>> 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 nobody Fri Aug 1 20:49:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95A1A038C for ; Fri, 1 Aug 2014 20:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx9sXGEGy721 for ; Fri, 1 Aug 2014 20:49:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D196A1A0387 for ; Fri, 1 Aug 2014 20:49:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU61583; Sat, 02 Aug 2014 03:49:37 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 2 Aug 2014 04:49:36 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Sat, 2 Aug 2014 11:49:29 +0800 From: "Shishufeng (Susan)" To: "lionel.morand@orange.com" , Steve Donovan Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPrfJk68dF5OCezEe+7yNvYXl1rJu8q6SA Date: Sat, 2 Aug 2014 03:49:28 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF61C7F@SZXEMA512-MBX.china.huawei.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> In-Reply-To: <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> Accept-Language: en-GB, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CRCCIC7MHdmIwLNQ367bamTCVIU Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2014 03:49:43 -0000 Hello, Whatever host-based report and realm-based report is in the same message or= not, my understanding is that host based report and realm based report are= serving for different purposes. If a message is to be sent to the host, th= en host report would be applied. If the client is unable to know the destin= ation host of the request, then realm report can be applied. If the client = is unable to see the hosts behind the agent, I cannot see the benefit to in= clude report of a specific host behind the agent. How to do the load balanc= ing and cope with overload of some hosts is the responsibility of the agent= . Best Regards, Susan -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Saturday, August 02, 2014 9:38 AM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) In this scenario and other similar scenari, my requirement will be to remov= e any host-based report and forward only realm-based reports. Any host-base= d would be useless for clients beyond the agent. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- True. So the question is, for this scenario, is it better for the client to ignor= e the overload report - as determined by there being a difference in the id= entity in the overload report and the identity in the origin-host AVP - or = for the client to apply the overload report to all traffic sent through the= agent? If we choose the latter then what happens when the client starts seeing ove= rload reports from multiple servers behind the agent? My instinct is that it is better for the client to ignore the report as not= doing so could result in a significant reduction in overall traffic sent t= hrough the non DOIC, origin-host munging agent. Steve On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: > But the client will never use the identity received in the OLR to check w= hich abatement to apply when sending a request to the server... that is the= agent from its point of view. > Therefore the client will never apply the overload abatement. > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > For host reports, the client would always use the identity in the=20 > report, not the identity in the origin-host AVP. > > Steve > > On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >> I understood! But what will be the use of this info by the client? As fo= r the client, the server is the identity of the Origin-host of the received= answer. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Steve Donovan a =E9crit ---- >> >> >> Lionel, >> >> The agent would not be inserting it's identity in the overload report. >> The proposal is that the DOIC node that inserted the overload report=20 >> includes its diameter identity in the overload report. As such, it=20 >> would be the server's identity that is in the overload report. >> >> Sorry if I wasn't clear. >> >> Steve >> >> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> So the topology hiding is not a relevant example here. Even with an ide= ntity inserted in the OLR, the client will never know to which server the r= equest is sent because the only relevant info for the client is the Origin-= host received in the answer i.e. the id of the agent. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 :=20 >>> vendredi 1 ao=FBt 2014 19:49 =C0 : MORAND Lionel IMT/OLN Cc :=20 >>> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports=20 >>> (was Re: DOIC issue #58 Proposal) >>> >>> Lionel, >>> >>> The issue is that there could be multiple/many servers behind the=20 >>> agent that is changing the Origin-Host. If one of them is=20 >>> overloaded and generates a host report, clients will apply overload=20 >>> abatement to all requests sent through that agent. The end result=20 >>> would be that the non overloaded servers are under utilized. >>> >>> Steve >>> >>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> Not sure to understand. If an agent inserts its identity as Origin-hos= t in answers forwarded from servers, the client will see the agent as the s= erver. >>>> What will be the added-value to add the identity of the server inserti= ng the OLR if the client will store this information along the agent id? >>>> Sorry if I've missed something... >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve=20 >>>> Donovan Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 Cc : dime@ietf.org=20 >>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue=20 >>>> #58 Proposal) >>>> >>>> Somewhat on on the path toward generalization, we have a second=20 >>>> issue currently open that can be solved by having the DOIC node=20 >>>> that inserts an overload report in an answer message include it's=20 >>>> own diameter identity in the overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >>>> >>>> This issue points out that existing non DOIC agents are able to=20 >>>> change the origin-host in answer messages. One example of where=20 >>>> this is done is in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports. >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group=20 >>>> AVP that carries the diameter identity of the DOIC node that=20 >>>> inserted the overload report into the answer message. Issue #66=20 >>>> points out the need in host reports and issue #58 points out the need = in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the host= report. Or, if a multiple (redundant or active-active) load-balancing agen= ts are generating the report, they must similarly be synchronized. >>>>>> >>>>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization requ= irement just to support DOIC. >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>> lionel.morand@orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>> >>>>>> Hi Steve, >>>>>> >>>>>> I agree with Nirav's view. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Lionel >>>>>> >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>> >>>>>> Steve, >>>>>> >>>>>> For this issue, I don't agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >>>>>> >>>>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>>>> >>>>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>>>> >>>>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>>>> >>>>>> Finally, I don't see any value-add of using the "identity of the=20 >>>>>> node that sends the realm-report" to discard the other report=20 >>>>>> related to the same realm. In other words, this same logic can be=20 >>>>>> achieved using sequence-numbers as well, i.e. when the=20 >>>>>> overload-report of an realm is active, the client is going to=20 >>>>>> ignore all the reports of the same realm which has lower sequence=20 >>>>>> number value. So in essence, when two agents are sending=20 >>>>>> realm-reports, one of the reports is automatically ignored by the=20 >>>>>> client if their sequence numbers differ. So the outcome without=20 >>>>>> including the "identity if the node that sends realm report" is=20 >>>>>> same as >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>> Donovan >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>> >>>>>> All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>>>> >>>>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes ma= y receive in different answer messages different realm-routed-request type = OLRs inserted by the different reporting nodes. Although it is expected tha= t the different reporting nodes report more or less the same content, it ca= nnot be expected that reports are 100% synchronized. Especially sequence nu= mbers may differ. To allow reacting nodes correctly detect outdates/replays= /freshness of OLRs in this scenario, it is proposed that realm-routed-reque= st type OLRs are extended to contain the Diameter Identity of the reporting= node that inserted the realm-routed-request type OLR. (e.g. as already pro= posed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert= realm-routed-request type OLRs to answer messages MUST also insert their D= iameter Identity. Reacting nodes MUST take the Diameter Identity received w= ithin the OLR into account in order to detect outdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only re= quired for realm reports. It would not be required for host reports as the= identity of the sender of the host report is implicitly defined by the ori= gin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing s= tate. To this end I propose that we add wording that for the duration of a= realm report, the reacting node only listens for updates to the realm repo= rt from from the DOIC node that sent the realm report that resulted in the = realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> _________________________________________________________________ >>>>>> ________________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> ___________________________________________________________________ >>>> ______________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles 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=20 >>>> privileged information that may be protected by law; they should not b= e 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. >>>> >>>> >>> ____________________________________________________________________ >>> _____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. From nobody Fri Aug 1 21:08:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731ED1A0395 for ; Fri, 1 Aug 2014 21:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-bUWbVEI8z7 for ; Fri, 1 Aug 2014 21:08:48 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2650A1A038F for ; Fri, 1 Aug 2014 21:08:48 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54608 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XDQcc-0004Hr-0O; Fri, 01 Aug 2014 21:08:44 -0700 Message-ID: <53DC6449.6030905@usdonovans.com> Date: Fri, 01 Aug 2014 23:08:41 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> In-Reply-To: <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/C1gRpKoRK1LffsArEcVGqwiGnL8 Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2014 04:08:51 -0000 The issue is that the agent in question is a non DOIC agent. This is a=20 backwards compatibility issue. Steve On 8/1/14, 8:37 PM, lionel.morand@orange.com wrote: > In this scenario and other similar scenari, my requirement will be to r= emove any host-based report and forward only realm-based reports. Any hos= t-based would be useless for clients beyond the agent. > > Regards, > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > True. > > So the question is, for this scenario, is it better for the client to > ignore the overload report - as determined by there being a difference > in the identity in the overload report and the identity in the > origin-host AVP - or for the client to apply the overload report to all= > traffic sent through the agent? > > If we choose the latter then what happens when the client starts seeing= > overload reports from multiple servers behind the agent? > > My instinct is that it is better for the client to ignore the report as= > not doing so could result in a significant reduction in overall traffic= > sent through the non DOIC, origin-host munging agent. > > Steve > > On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: >> But the client will never use the identity received in the OLR to chec= k which abatement to apply when sending a request to the server... that i= s the agent from its point of view. >> Therefore the client will never apply the overload abatement. >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Steve Donovan a =E9crit ---- >> >> >> For host reports, the client would always use the identity in the >> report, not the identity in the origin-host AVP. >> >> Steve >> >> On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >>> I understood! But what will be the use of this info by the client? As= for the client, the server is the identity of the Origin-host of the rec= eived answer. >>> >>> Lionel >>> >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> >>> ---- Steve Donovan a =E9crit ---- >>> >>> >>> Lionel, >>> >>> The agent would not be inserting it's identity in the overload report= =2E >>> The proposal is that the DOIC node that inserted the overload report >>> includes its diameter identity in the overload report. As such, it >>> would be the server's identity that is in the overload report. >>> >>> Sorry if I wasn't clear. >>> >>> Steve >>> >>> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> So the topology hiding is not a relevant example here. Even with an = identity inserted in the OLR, the client will never know to which server = the request is sent because the only relevant info for the client is the = Origin-host received in the answer i.e. the id of the agent. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >>>> =C0 : MORAND Lionel IMT/OLN >>>> Cc : dime@ietf.org >>>> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC iss= ue #58 Proposal) >>>> >>>> Lionel, >>>> >>>> The issue is that there could be multiple/many servers behind the ag= ent >>>> that is changing the Origin-Host. If one of them is overloaded and >>>> generates a host report, clients will apply overload abatement to al= l >>>> requests sent through that agent. The end result would be that the = non >>>> overloaded servers are under utilized. >>>> >>>> Steve >>>> >>>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>>> Hi Steve, >>>>> >>>>> Not sure to understand. If an agent inserts its identity as Origin-= host in answers forwarded from servers, the client will see the agent as = the server. >>>>> What will be the added-value to add the identity of the server inse= rting the OLR if the client will store this information along the agent i= d? >>>>> Sorry if I've missed something... >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donova= n >>>>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>>>> Cc : dime@ietf.org >>>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) >>>>> >>>>> Somewhat on on the path toward generalization, we have a second iss= ue >>>>> currently open that can be solved by having the DOIC node that inse= rts >>>>> an overload report in an answer message include it's own diameter >>>>> identity in the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origi= n-Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to cha= nge >>>>> the origin-host in answer messages. One example of where this is d= one >>>>> is in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports= =2E >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group A= VP >>>>> that carries the diameter identity of the DOIC node that inserted t= he >>>>> overload report into the answer message. Issue #66 points out the = need >>>>> in host reports and issue #58 points out the need in realm reports.= >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wro= te: >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the sa= me vendor and use a proprietary communication protocol to synchronize the= host report. Or, if a multiple (redundant or active-active) load-balanci= ng agents are generating the report, they must similarly be synchronized.= >>>>>>> >>>>>>> Is seems like including the host name per Ulrich's suggestion is = a simple way of avoiding proprietary mechanisms or coupling between hosts= and agents. >>>>>>> In some applications, the hosts can be completely decoupled (agno= stic about each other). I think it would be poor to add a synchronization= requirement just to support DOIC. >>>>>>> >>>>>>> -Dave >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.mor= and@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>>> >>>>>>> Hi Steve, >>>>>>> >>>>>>> I agree with Nirav's view. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Lionel >>>>>>> >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>>> >>>>>>> Steve, >>>>>>> >>>>>>> For this issue, I don't agree to include identity of the DOIC nod= e that sends the report, into the realm reports. >>>>>>> >>>>>>> In my view, the issue mentioned below - of two agents not 100% sy= nchronize w.r.t the realm-report - is the related to "how agents synchron= ized between themselves" and since that is not standardized we should not= be developing protocol solution for the case which occurs due to this ou= t-of-standards solution. >>>>>>> >>>>>>> Besides, I don't see any issue due to slight miss-synchronization= of the realm-reports between two agents since they should still represen= t the realm load more or less accurately. >>>>>>> >>>>>>> Also if the agents are not synchronized and if they are playing t= he role of DOIC reacting node then they will apply abatement algorithm ba= sed on different values (for the same realm). So it does not matter if th= e client does the same. >>>>>>> >>>>>>> Finally, I don't see any value-add of using the "identity of the = node that sends the realm-report" to discard the other report related to = the same realm. In other words, this same logic can be achieved using seq= uence-numbers as well, i.e. when the overload-report of an realm is activ= e, the client is going to ignore all the reports of the same realm which = has lower sequence number value. So in essence, when two agents are sendi= ng realm-reports, one of the reports is automatically ignored by the clie= nt if their sequence numbers differ. So the outcome without including the= "identity if the node that sends realm report" is same as >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Dono= van >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descr= iption: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take th= e role of a reporting node for realm-routed-request reports, reacting nod= es may receive in different answer messages different realm-routed-reques= t type OLRs inserted by the different reporting nodes. Although it is exp= ected that the different reporting nodes report more or less the same con= tent, it cannot be expected that reports are 100% synchronized. Especiall= y sequence numbers may differ. To allow reacting nodes correctly detect o= utdates/replays/freshness of OLRs in this scenario, it is proposed that r= ealm-routed-request type OLRs are extended to contain the Diameter Identi= ty of the reporting node that inserted the realm-routed-request type OLR.= (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Repo= rting nodes that insert realm-routed-request type OLRs to answer messages= MUST also insert their Diameter Identity. Reacting nodes MUST take the D= iameter Identity received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP on= ly required for realm reports. It would not be required for host reports= as the identity of the sender of the host report is implicitly defined b= y the origin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update exist= ing state. To this end I propose that we add wording that for the durati= on of a realm report, the reacting node only listens for updates to the r= ealm report from from the DOIC node that sent the realm report that resul= ted in the realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will o= nly listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> _________________________________________________________________= ________________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des information= s 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 m= essages electroniques etant susceptibles d'alteration, >>>>>>> Orange decline toute responsabilite si ce message a ete altere, d= eforme ou falsifie. Merci. >>>>>>> >>>>>>> This message and its attachments may contain confidential or priv= ileged information that may be protected by law; >>>>>>> they should not be distributed, used or copied without authorisat= ion. >>>>>>> If you have received this email in error, please notify the sende= r 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. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> ___________________________________________________________________= ______________________________________________________ >>>>> >>>>> 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 a= vez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or privil= eged information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisatio= n. >>>>> 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 ha= ve been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> >>>> ____________________________________________________________________= _____________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations c= onfidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privile= ged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation= =2E >>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>> Thank you. >>>> >>>> >>> _____________________________________________________________________= ____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>> >>> >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d 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. >> >> > > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Sun Aug 3 21:37:24 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62421A0114 for ; Sun, 3 Aug 2014 21:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRjz4ZaUoHwE for ; Sun, 3 Aug 2014 21:37:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4EE1A0111 for ; Sun, 3 Aug 2014 21:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9783; q=dns/txt; s=iport; t=1407127040; x=1408336640; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5VaJuyNKzpXTO0YQSUmvFa+/t4bSY9GH1Yd2Nq2Bosk=; b=NtZD33gkn62IjUqi9crKbKB9BGJ+S/p4D5bEIvGZwxLxY+Qlc5skT8pi oPALcFqEmLncp7GA652pk9pzCaXF/pCdu8Igv49l2jwviNQgUPlMiwbWT OKj7nfdJwXNkhY9ZITgLcY1VjGlMxTVk6qOapA7U4qu3qqTu7sabMrvpG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAwN31OtJA2N/2dsb2JhbABSCYMNUlcEzA4Kh0wBgRcWd4QDAQEBBAEBAWQHCwwEAgEIEQQBAQEKCxIHJwsUCQgCBAENBQgTiCcNxWkTBIwKgmAHCgEfMQcGBIMlgRwFilWNBZkLg01sgQ05 X-IronPort-AV: E=Sophos;i="5.01,795,1400025600"; d="scan'208";a="344851642" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 04 Aug 2014 04:37:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s744bJ4B000606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 04:37:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Sun, 3 Aug 2014 23:37:19 -0500 From: "Nirav Salot (nsalot)" To: "Shishufeng (Susan)" , Steve Donovan , Ben Campbell Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8buoAgAAOQgCAAIGHAIAC4R8A Date: Mon, 4 Aug 2014 04:37:18 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.35.230] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SGPV7w9YY-7Tv0aijMgLqsPraeI Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 04:37:23 -0000 I fully agree with Susan below and I don't see any value in adding identity= of the host in the overload report. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Susan) Sent: Saturday, August 02, 2014 9:07 AM To: Steve Donovan; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Hello, I really don't understand the logic for the host to insert its own identity= into the overload report. Wouldn't it be the host to report its own overlo= ad report in an answer message to the client? Why we need the agent to do a= nything in this case? To say the least, if the host can insert its identity into the message, wha= t's the benefit to have the agent for topology hiding? Best Regards, Susan -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Saturday, August 02, 2014 3:54 AM To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Yes, it could be either. The critical point is that the overloaded host is= indicated by the diameter id in the overload report, not the origin-host A= VP. Steve On 8/1/14, 2:02 PM, Ben Campbell wrote: > I don't think you can conflate "host that generated this OLR" with=20 > "host that is overloaded". It's perfectly valid for them to not be the=20 > same thing, even for host reports. (But I'd be happy to include > both.) > > On Aug 1, 2014, at 11:09 AM, Steve Donovan wro= te: > >> Somewhat on on the path toward generalization, we have a second issue cu= rrently open that can be solved by having the DOIC node that inserts an ove= rload report in an answer message include it's own diameter identity in the= overload report. >> >> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Hos= t. >> >> This issue points out that existing non DOIC agents are able to change t= he origin-host in answer messages. One example of where this is done is in= topology hiding implementations. >> >> This issue can be addressed through attribution of overload reports. >> >> As such, I propose that we add a required AVP to the OC-OLR group AVP th= at carries the diameter identity of the DOIC node that inserted the overloa= d report into the answer message. Issue #66 points out the need in host re= ports and issue #58 points out the need in realm reports. >> >> Steve >> >> >> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>> +1 (modulo my comment to generalize) >>> >>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>> >>>> I believe Nirav's view requires all hosts in a realm to be the same ve= ndor and use a proprietary communication protocol to synchronize the host r= eport. Or, if a multiple (redundant or active-active) load-balancing agents= are generating the report, they must similarly be synchronized. >>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>> In some applications, the hosts can be completely decoupled (agnostic = about each other). I think it would be poor to add a synchronization requir= ement just to support DOIC. >>>> -Dave >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>> lionel.morand@orange.com >>>> Sent: Friday, August 01, 2014 6:58 AM >>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>> Hi Steve, >>>> I agree with Nirav's view. >>>> Regards, >>>> Lionel >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> Steve, >>>> For this issue, I don't agree to include identity of the DOIC node t= hat sends the report, into the realm reports. >>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>> Finally, I don't see any value-add of using the "identity of the=20 >>>> node that sends the realm-report" to discard the other report=20 >>>> related to the same realm. In other words, this same logic can be=20 >>>> achieved using sequence-numbers as well, i.e. when the=20 >>>> overload-report of an realm is active, the client is going to=20 >>>> ignore all the reports of the same realm which has lower sequence=20 >>>> number value. So in essence, when two agents are sending=20 >>>> realm-reports, one of the reports is automatically ignored by the=20 >>>> client if their sequence numbers differ. So the outcome without=20 >>>> including the "identity if the node that sends realm report" is=20 >>>> same as >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>> Regards, >>>> Nirav. >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>> Donovan >>>> Sent: Friday, August 01, 2014 1:23 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] DOIC issue #58 Proposal >>>> All, >>>> >>>> Issue #58 deals with the fact that there can be multiple senders of re= alm overload report for the same realm. >>>> >>>> Ulrich proposes one aspect of what is required in the issue descriptio= n: >>>> >>>> "In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that = the different reporting nodes report more or less the same content, it cann= ot be expected that reports are 100% synchronized. Especially sequence numb= ers may differ. To allow reacting nodes correctly detect outdates/replays/f= reshness of OLRs in this scenario, it is proposed that realm-routed-request= type OLRs are extended to contain the Diameter Identity of the reporting n= ode that inserted the realm-routed-request type OLR. (e.g. as already propo= sed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert r= ealm-routed-request type OLRs to answer messages MUST also insert their Dia= meter Identity. Reacting nodes MUST take the Diameter Identity received wit= hin the OLR into account in order to detect outdates/replays/freshness." >>>> >>>> I agree with Ulrich that realm reports must include the identity of th= e DOIC node that sends the report. This would be an optional AVP only requ= ired for realm reports. It would not be required for host reports as the i= dentity of the sender of the host report is implicitly defined by the origi= n-host in the answer message. >>>> >>>> I also agree that the Diameter Identity of the reporting node be used = to determine if a received report is ignored or used to update existing sta= te. To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report= from from the DOIC node that sent the realm report that resulted in the re= alm OCS being stored. >>>> >>>> The effect should be that the reacting node will accept a realm report= from anyone when there is no active OLR for the realm but it will only lis= ten to one reporting node when it has an active report. >>>> >>>> Steve >>>> >>>> >>>> ______________________________________________________________________= ___________________________________________________ >>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>> informations confidentielles ou privilegiees et ne doivent donc pas=20 >>>> etre diffuses, exploites ou copies sans autorisation. Si vous avez=20 >>>> recu ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant sus= ceptibles 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=20 >>>> privileged information that may be protected by law; they should not b= e 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. >>>> _______________________________________________ >>>> 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 nobody Sun Aug 3 21:45:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FD91A0114 for ; Sun, 3 Aug 2014 21:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMlyv7TOs24z for ; Sun, 3 Aug 2014 21:45:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FB41A011D for ; Sun, 3 Aug 2014 21:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19500; q=dns/txt; s=iport; t=1407127546; x=1408337146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E1OSGrXC1vDnyWsphI4HGtzewWS/Hjc6EQW8RcPOc30=; b=EVVIiXM9Hk6UakhVMQ7ymkHyCDDTwYmZAQK8uPHvRMZ02UleRp5IzR59 HqFuAEuHTji2rIVIRCgg91Amq71WWqER2YxSlIA0FIEvMDxSPJG19HuqV 3Ps/joF8mbgVRQN3QDuos1mxInWH+DwYjmcZtL7zY/9ag+IshTMLvh3uO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOcO31OtJA2K/2dsb2JhbABSCYMNUlcEzA4Kh0wBgRcWd4QDAQEBBAEBAWQHCwwEAgEIDgMEAQEBCgsSBycLFAkIAgQBDQUIE4gnDcVpEwSMCoJgBwoBDhExBwYEgyWBHAWKVY0FmQuDTWyBBgcXIg X-IronPort-AV: E=Sophos;i="5.01,795,1400025600"; d="scan'208";a="344917800" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 04 Aug 2014 04:45:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s744jh2X014608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 04:45:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sun, 3 Aug 2014 23:45:43 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "lionel.morand@orange.com" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8QG4AgAAZ2YCAAAW4gIAABbIAgAAESwCAAAOAgIAAJFYAgAAP7wCAADt4gIAAKjWAgALZK9A= Date: Mon, 4 Aug 2014 04:45:42 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> <53DC6449.6030905@usdonovans.com> In-Reply-To: <53DC6449.6030905@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.35.230] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ADXnT14_OpeYBZ3hPiI_JLLsW3g Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 04:45:49 -0000 Steve, How would topology hiding is achieved if the OLR has host's identity? So the solution in this case is to turn-off the topology hiding feature at = the agent so that the client receives identity of the host in the Origin-Ho= st and applies abatement accordingly. The other solution is to turn-off the generation of OLR at the host since t= he agents - which are supposed to consume the host's OLR in the topology hi= ding case - are not upgraded to support DOIC (i.e. are non DOIC agent yet). I don't see inclusion of host's identity in the OLR as the solution for the= problem - i.e. when the non DOIC agent is doing topology hiding - we are t= rying to solve here. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Saturday, August 02, 2014 9:39 AM To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) The issue is that the agent in question is a non DOIC agent. This is a bac= kwards compatibility issue. Steve On 8/1/14, 8:37 PM, lionel.morand@orange.com wrote: > In this scenario and other similar scenari, my requirement will be to rem= ove any host-based report and forward only realm-based reports. Any host-ba= sed would be useless for clients beyond the agent. > > Regards, > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Steve Donovan a =E9crit ---- > > > True. > > So the question is, for this scenario, is it better for the client to=20 > ignore the overload report - as determined by there being a difference=20 > in the identity in the overload report and the identity in the=20 > origin-host AVP - or for the client to apply the overload report to=20 > all traffic sent through the agent? > > If we choose the latter then what happens when the client starts=20 > seeing overload reports from multiple servers behind the agent? > > My instinct is that it is better for the client to ignore the report=20 > as not doing so could result in a significant reduction in overall=20 > traffic sent through the non DOIC, origin-host munging agent. > > Steve > > On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: >> But the client will never use the identity received in the OLR to check = which abatement to apply when sending a request to the server... that is th= e agent from its point of view. >> Therefore the client will never apply the overload abatement. >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Steve Donovan a =E9crit ---- >> >> >> For host reports, the client would always use the identity in the=20 >> report, not the identity in the origin-host AVP. >> >> Steve >> >> On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >>> I understood! But what will be the use of this info by the client? As f= or the client, the server is the identity of the Origin-host of the receive= d answer. >>> >>> Lionel >>> >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> >>> ---- Steve Donovan a =E9crit ---- >>> >>> >>> Lionel, >>> >>> The agent would not be inserting it's identity in the overload report. >>> The proposal is that the DOIC node that inserted the overload report=20 >>> includes its diameter identity in the overload report. As such, it=20 >>> would be the server's identity that is in the overload report. >>> >>> Sorry if I wasn't clear. >>> >>> Steve >>> >>> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> So the topology hiding is not a relevant example here. Even with an id= entity inserted in the OLR, the client will never know to which server the = request is sent because the only relevant info for the client is the Origin= -host received in the answer i.e. the id of the agent. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 :=20 >>>> vendredi 1 ao=FBt 2014 19:49 =C0 : MORAND Lionel IMT/OLN Cc :=20 >>>> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports=20 >>>> (was Re: DOIC issue #58 Proposal) >>>> >>>> Lionel, >>>> >>>> The issue is that there could be multiple/many servers behind the=20 >>>> agent that is changing the Origin-Host. If one of them is=20 >>>> overloaded and generates a host report, clients will apply overload=20 >>>> abatement to all requests sent through that agent. The end result=20 >>>> would be that the non overloaded servers are under utilized. >>>> >>>> Steve >>>> >>>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>>> Hi Steve, >>>>> >>>>> Not sure to understand. If an agent inserts its identity as Origin-ho= st in answers forwarded from servers, the client will see the agent as the = server. >>>>> What will be the added-value to add the identity of the server insert= ing the OLR if the client will store this information along the agent id? >>>>> Sorry if I've missed something... >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve=20 >>>>> Donovan Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 Cc : dime@ietf.org=20 >>>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue=20 >>>>> #58 Proposal) >>>>> >>>>> Somewhat on on the path toward generalization, we have a second=20 >>>>> issue currently open that can be solved by having the DOIC node=20 >>>>> that inserts an overload report in an answer message include it's=20 >>>>> own diameter identity in the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-= Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to=20 >>>>> change the origin-host in answer messages. One example of where=20 >>>>> this is done is in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports. >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group=20 >>>>> AVP that carries the diameter identity of the DOIC node that=20 >>>>> inserted the overload report into the answer message. Issue #66=20 >>>>> points out the need in host reports and issue #58 points out the need= in realm reports. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote= : >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the same= vendor and use a proprietary communication protocol to synchronize the hos= t report. Or, if a multiple (redundant or active-active) load-balancing age= nts are generating the report, they must similarly be synchronized. >>>>>>> >>>>>>> Is seems like including the host name per Ulrich's suggestion is a = simple way of avoiding proprietary mechanisms or coupling between hosts and= agents. >>>>>>> In some applications, the hosts can be completely decoupled (agnost= ic about each other). I think it would be poor to add a synchronization req= uirement just to support DOIC. >>>>>>> >>>>>>> -Dave >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>> lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>>> >>>>>>> Hi Steve, >>>>>>> >>>>>>> I agree with Nirav's view. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Lionel >>>>>>> >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>>> >>>>>>> Steve, >>>>>>> >>>>>>> For this issue, I don't agree to include identity of the DOIC node = that sends the report, into the realm reports. >>>>>>> >>>>>>> In my view, the issue mentioned below - of two agents not 100% sync= hronize w.r.t the realm-report - is the related to "how agents synchronized= between themselves" and since that is not standardized we should not be de= veloping protocol solution for the case which occurs due to this out-of-sta= ndards solution. >>>>>>> >>>>>>> Besides, I don't see any issue due to slight miss-synchronization o= f the realm-reports between two agents since they should still represent th= e realm load more or less accurately. >>>>>>> >>>>>>> Also if the agents are not synchronized and if they are playing the= role of DOIC reacting node then they will apply abatement algorithm based = on different values (for the same realm). So it does not matter if the clie= nt does the same. >>>>>>> >>>>>>> Finally, I don't see any value-add of using the "identity of the=20 >>>>>>> node that sends the realm-report" to discard the other report=20 >>>>>>> related to the same realm. In other words, this same logic can=20 >>>>>>> be achieved using sequence-numbers as well, i.e. when the=20 >>>>>>> overload-report of an realm is active, the client is going to=20 >>>>>>> ignore all the reports of the same realm which has lower=20 >>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>> ignored by the client if their sequence numbers differ. So the=20 >>>>>>> outcome without including the "identity if the node that sends=20 >>>>>>> realm report" is same as >>>>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>>> Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders of= realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descrip= tion: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting nodes m= ay receive in different answer messages different realm-routed-request type= OLRs inserted by the different reporting nodes. Although it is expected th= at the different reporting nodes report more or less the same content, it c= annot be expected that reports are 100% synchronized. Especially sequence n= umbers may differ. To allow reacting nodes correctly detect outdates/replay= s/freshness of OLRs in this scenario, it is proposed that realm-routed-requ= est type OLRs are extended to contain the Diameter Identity of the reportin= g node that inserted the realm-routed-request type OLR. (e.g. as already pr= oposed in draft-donovan-dime-agent-overload-01). Reporting nodes that inser= t realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity received = within the OLR into account in order to detect outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity of= the DOIC node that sends the report. This would be an optional AVP only r= equired for realm reports. It would not be required for host reports as th= e identity of the sender of the host report is implicitly defined by the or= igin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be us= ed to determine if a received report is ignored or used to update existing = state. To this end I propose that we add wording that for the duration of = a realm report, the reacting node only listens for updates to the realm rep= ort from from the DOIC node that sent the realm report that resulted in the= realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> _________________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'expe= diteur et le detruire ainsi que les pieces jointes. Les messages electroniq= ues 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=20 >>>>>>> privileged information that may be protected by law; they should no= t 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 ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> __________________________________________________________________ >>>>> _______________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles 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=20 >>>>> 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 an= d 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. >>>>> >>>>> >>>> ___________________________________________________________________ >>>> ______________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles 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=20 >>>> privileged information that may be protected by law; they should not b= e 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. >>>> >>>> >>> ____________________________________________________________________ >>> _____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Sun Aug 3 21:55:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E921B2852 for ; Sun, 3 Aug 2014 21:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr9BHSmYSX3p for ; Sun, 3 Aug 2014 21:55:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349411B284F for ; Sun, 3 Aug 2014 21:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47353; q=dns/txt; s=iport; t=1407128129; x=1408337729; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dAgUPMQ/7iK+sK5Q3v/V7EKrq7BmHAW/zslgTT78+Og=; b=baeFd6xKajW2LPZDiMSV1APFB+Kzj0vJZ9BEPovh8/2nmqqiWXXncC3d cOv0zFRR+SQnIWb+ieUBiU38k24IfCOfE3b6TfPIwhP8HesJds8pi/Q/Y HdskAXyWo5LvrqsPKo0Mtw94BK2GS0mNeDuK6Db2PKs4aaybx2HL1yXuf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAIER31OtJV2T/2dsb2JhbABSCYJHRlJXBMo1gWOHTAGBFxZ3hAMBAQEDARoTRwoLAgEIDgMEAQELCwsBBgcyFAkIAgQBEggTiB8IDcVnF45qBwoBHzcBBgSDJYEcBYpVhCKIY4YAkwuDTWyBBAcCFyI X-IronPort-AV: E=Sophos;i="5.01,795,1400025600"; d="scan'208,217";a="344837184" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 04 Aug 2014 04:55:26 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s744tQG0006877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 04:55:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sun, 3 Aug 2014 23:55:26 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "lionel.morand@orange.com" , Dave Dolson , "dime@ietf.org" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrPj5lwrN9479MEmgKHB41eF0/5u7N7ZAgACxMQCAAECkAIAAEyqA//+uAICAAIEngIADeSbw Date: Mon, 4 Aug 2014 04:55:25 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBE0AB.4040505@usdonovans.com> In-Reply-To: <53DBE0AB.4040505@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.35.230] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA018DDE42Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BACozKClcpBW426YMGVHdq3vvv4 Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 04:55:38 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA018DDE42Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, In this scenario, > Now, assume that the realm report generators lose the ability to communic= ate due to some localized failure. The realm is known to be overloaded so = realm reports need to be sent. Assume also that one of the realm report ge= nerators thinks a 10% reduction is needed and a second thinks a 50% reducti= on is needed. Can you explain how did you come to this conclusion? > One effect can be a thrashing between 10% reduction and 50% reduction. The client will ignore the report with lower sequence number and so I don't= see the thrashing between 10% and 50%. Regards, Nirav. From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Saturday, August 02, 2014 12:17 AM To: Nirav Salot (nsalot); lionel.morand@orange.com; Dave Dolson; dime@ietf.= org Subject: Re: [Dime] DOIC issue #58 Proposal The question becomes, what happens if the nodes that are sending the realm = reports lose the ability to stay in synchronization. We all know that comm= unication can be lost between entities. This is what leads to complicated,= multiple stage protocols for things like database synchronization. So, lets assume that we mandate that DOIC nodes that send realm reports (le= t's call them realm report generators) MUST be in sync and that includes bo= th the sequence number and any abatement algorithm data (percentage reducti= on for the loss algorithm). A side note -- let's stop assuming that the realm report generator is an ag= ent. There is nothing saying that agents are the only thing that can send = realm reports. It is perfectly valid for servers to send realm report if t= hey have visibility to the state of the realm as a whole. Now, assume that the realm report generators lose the ability to communicat= e due to some localized failure. The realm is known to be overloaded so re= alm reports need to be sent. Assume also that one of the realm report gene= rators thinks a 10% reduction is needed and a second thinks a 50% reduction= is needed. A client is going to see both reports types. The realm report generators a= re going to refresh the reports, sending new reports with higher sequence n= umbers. The client will honor all reports that have a bigger sequence numb= er. One effect can be a thrashing between 10% reduction and 50% reduction. This is clearly an edge case. It is, however, an edge case that is easily = avoidable by attributing the source of the realm report. Steve On 8/1/14, 11:12 AM, Nirav Salot (nsalot) wrote: Hi Dave, On top of what Lionel mentioned, if you look at issue #58, we are already a= ssuming that agents providing report for the same realm are almost synchron= ized. > Although it is expected that the different reporting nodes report more or= less the same content, it cannot be expected that reports are 100% synchro= nized. Especially sequence numbers may differ. The issue we are solving is when there is slight miss-synchronization betwe= en those agents - for whatever reason - how does the client handle it. > To allow reacting nodes correctly detect outdates/replays/freshness of OL= Rs in this scenario, it is proposed that realm-routed-request type OLRs are= extended to contain the Diameter Identity of the reporting node that inser= ted the realm-routed-request type OLR. And that's where we are proposing to use "identity of agent providing realm= report". The client receives same report with two different identities (fr= om two different agents) and discard one of them. > Reacting nodes MUST take the Diameter Identity received within the OLR in= to account in order to detect outdates/replays/freshness. My main point was that, the same logic - of discarding report from one of t= he agent - can be achieved by using sequence number, which is already provi= ded as part of overload report. So in summary, there is no value in adding "Diameter identity of the agent = providing realm-report" for issue #58. Just to clarify, I am not assuming same vendor providing the agents. And, I= guess, that is not relevant to issue #58. Regards, Nirav. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, August 01, 2014 9:28 PM To: Dave Dolson; Steve Donovan; dime@ietf.org; Nirav = Salot (nsalot) Subject: RE: [Dime] DOIC issue #58 Proposal Hi Dave, The whole purpose of "Realm" report is to provide a consolidated view of th= e overload status of all the servers in the realm. If you are not able to provide such consolidated view for the entire realm,= you will not be able to send OLR with the type "Realm". The synchronization between nodes might not be required but it is required = that all the agents providing Realm-based OLR have the means to provide a "= common" view, whatever the mechanism used for that. Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 1 ao=FBt 2014 16:50 =C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) Objet : RE: [Dime] DOIC issue #58 Proposal I believe Nirav's view requires all hosts in a realm to be the same vendor = and use a proprietary communication protocol to synchronize the host report= . Or, if a multiple (redundant or active-active) load-balancing agents are = generating the report, they must similarly be synchronized. Is seems like including the host name per Ulrich's suggestion is a simple w= ay of avoiding proprietary mechanisms or coupling between hosts and agents. In some applications, the hosts can be completely decoupled (agnostic about= each other). I think it would be poor to add a synchronization requirement= just to support DOIC. -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Friday, August 01, 2014 6:58 AM To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot= ) Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree with Nirav's view. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. In my view, the issue mentioned below - of two agents not 100% synchronize = w.r.t the realm-report - is the related to "how agents synchronized between= themselves" and since that is not standardized we should not be developing= protocol solution for the case which occurs due to this out-of-standards s= olution. Besides, I don't see any issue due to slight miss-synchronization of the re= alm-reports between two agents since they should still represent the realm = load more or less accurately. Also if the agents are not synchronized and if they are playing the role of= DOIC reacting node then they will apply abatement algorithm based on diffe= rent values (for the same realm). So it does not matter if the client does = the same. Finally, I don't see any value-add of using the "identity of the node that = sends the realm-report" to discard the other report related to the same rea= lm. In other words, this same logic can be achieved using sequence-numbers = as well, i.e. when the overload-report of an realm is active, the client is= going to ignore all the reports of the same realm which has lower sequence= number value. So in essence, when two agents are sending realm-reports, on= e of the reports is automatically ignored by the client if their sequence n= umbers differ. So the outcome without including the "identity if the node t= hat sends realm report" is same as >The effect should be that the reacting node will accept a realm report fro= m anyone when there is no active OLR for the realm but it will only listen = to one reporting node when it has an active report. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 1:23 AM To: dime@ietf.org Subject: [Dime] DOIC issue #58 Proposal All, Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of = a reporting node for realm-routed-request reports, reacting nodes may recei= ve in different answer messages different realm-routed-request type OLRs in= serted by the different reporting nodes. Although it is expected that the d= ifferent reporting nodes report more or less the same content, it cannot be= expected that reports are 100% synchronized. Especially sequence numbers m= ay differ. To allow reacting nodes correctly detect outdates/replays/freshn= ess of OLRs in this scenario, it is proposed that realm-routed-request type= OLRs are extended to contain the Diameter Identity of the reporting node t= hat inserted the realm-routed-request type OLR. (e.g. as already proposed i= n draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-req= uest type OLRs to answer messages MUST also insert their Diameter Identity.= Reacting nodes MUST take the Diameter Identity received within the OLR int= o account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report. This would be an optional AVP only required = for realm reports. It would not be required for host reports as the identi= ty of the sender of the host report is implicitly defined by the origin-hos= t in the answer message. I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state. = To this end I propose that we add wording that for the duration of a realm = report, the reacting node only listens for updates to the realm report from= from the DOIC node that sent the realm report that resulted in the realm O= CS being stored. The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report. Steve ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_A9CA33BB78081F478946E4F34BF9AAA018DDE42Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

In this scenario,

> Now, assume t= hat the realm report generators lose the ability to communicate due to some= localized failure.  The realm is known to be overloaded so realm reports need to be sent.  Assume also that one of the realm rep= ort generators thinks a 10% reduction is needed and a second thinks a 50% r= eduction is needed.

 <= /p>

Can you explain how did y= ou come to this conclusion?

> One effect ca= n be a thrashing between 10% reduction and 50% reduction.

 <= /p>

The client will ignore th= e report with lower sequence number and so I don’t see the thrashing = between 10% and 50%.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Saturday, August 02, 2014 12:17 AM
To: Nirav Salot (nsalot); lionel.morand@orange.com; Dave Dolson; dim= e@ietf.org
Subject: Re: [Dime] DOIC issue #58 Proposal

 

The question becomes,= what happens if the nodes that are sending the realm reports lose the abil= ity to stay in synchronization.  We all know that communication can be= lost between entities.  This is what leads to complicated, multiple stage protocols for things like database synchron= ization.

So, lets assume that we mandate that DOIC nodes that send realm reports (le= t's call them realm report generators) MUST be in sync and that includes bo= th the sequence number and any abatement algorithm data (percentage reducti= on for the loss algorithm).

A side note -- let's stop assuming that the realm report generator is an ag= ent.  There is nothing saying that agents are the only thing that can = send realm reports.  It is perfectly valid for servers to send realm r= eport if they have visibility to the state of the realm as a whole.

Now, assume that the realm report generators lose the ability to communicat= e due to some localized failure.  The realm is known to be overloaded = so realm reports need to be sent.  Assume also that one of the realm r= eport generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed.

A client is going to see both reports types.  The realm report generat= ors are going to refresh the reports, sending new reports with higher seque= nce numbers.  The client will honor all reports that have a bigger seq= uence number. 

One effect can be a thrashing between 10% reduction and 50% reduction.

This is clearly an edge case.  It is, however, an edge case that is ea= sily avoidable by attributing the source of the realm report.

Steve

On 8/1/14, 11:12 AM, Nirav Salot (nsalot) wrote:

Hi Dave,

 <= /p>

On top of what Lionel men= tioned, if you look at issue #58, we are already assuming that agents provi= ding report for the same realm are almost synchronized.

> Although it i= s expected that the different reporting nodes report more or less the same = content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ.

The issue we are solving = is when there is slight miss-synchronization between those agents – f= or whatever reason – how does the client handle it.=

> To allow reac= ting nodes correctly detect outdates/replays/freshness of OLRs in this scen= ario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inser= ted the realm-routed-request type OLR.

 <= /p>

And that’s where we= are proposing to use "identity of agent providing realm report".= The client receives same report with two different identities (from two different agents) and discard one of them.

> Reacting node= s MUST take the Diameter Identity received within the OLR into account in o= rder to detect outdates/replays/freshness.

My main point was that, t= he same logic – of discarding report from one of the agent – ca= n be achieved by using sequence number, which is already provided as part of overload report.

So in summary, there is n= o value in adding "Diameter identity of the agent providing realm-repo= rt" for issue #58.

 <= /p>

Just to clarify, I am not= assuming same vendor providing the agents. And, I guess, that is not relev= ant to issue #58.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, August 01, 2014 9:28 PM
To: Dave Dolson; Steve Donovan; dim= e@ietf.org; Nirav Salot (nsalot)
Subject: RE: [Dime] DOIC issue #58 Proposal

 

Hi Dave,

 <= /p>

The whole purpose of &quo= t;Realm" report is to provide a consolidated view of the overload stat= us of all the servers in the realm.

If you are not able to pr= ovide such consolidated view for the entire realm, you will not be able to = send OLR with the type "Realm".

The synchronization betwe= en nodes might not be required but it is required that all the agents provi= ding Realm-based OLR have the means to provide a "common" view, whatever the mechanism used for that.

 <= /p>

Lionel<= /p>

 <= /p>

 <= /p>

De = : Dave Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 1 ao=FBt 2014 16:50
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org; Nirav Salot (nsalot)
Objet : RE: [Dime] DOIC issue #58 Proposal

 

I believe Nirav’s v= iew requires all hosts in a realm to be the same vendor and use a proprieta= ry communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are gener= ating the report, they must similarly be synchronized.

 <= /p>

Is seems like including t= he host name per Ulrich’s suggestion is a simple way of avoiding prop= rietary mechanisms or coupling between hosts and agents.<= /p>

In some applications, the= hosts can be completely decoupled (agnostic about each other). I think it = would be poor to add a synchronization requirement just to support DOIC.

 <= /p>

-Dave

 <= /p>

 <= /p>

 <= /p>

 

Hi Steve,
 
I agree with Nirav's view. 
 
Regards,
 
Lionel 
 
Envoy=E9 depuis mon Sony Xperia SP d'Orange
 
---- Nirav Salot (nsalot) a =E9crit ----=

 

Steve,<= /p>

 <= /p>

For this issue, I donR= 17;t agree to include identity of the DOIC node that sends the report, into= the realm reports.

 <= /p>

In my view, the issue men= tioned below – of two agents not 100% synchronize w.r.t the realm-rep= ort – is the related to "how agents synchronized between themsel= ves" and since that is not standardized we should not be developing protocol so= lution for the case which occurs due to this out-of-standards solution.

 <= /p>

Besides, I don’t se= e any issue due to slight miss-synchronization of the realm-reports between= two agents since they should still represent the realm load more or less accurately.

 <= /p>

Also if the agents are no= t synchronized and if they are playing the role of DOIC reacting node then = they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same.

 <= /p>

Finally, I don’t se= e any value-add of using the "identity of the node that sends the real= m-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as wel= l, i.e. when the overload-report of an realm is active, the client is going= to ignore all the reports of the same realm which has lower sequence numbe= r value. So in essence, when two agents are sending realm-reports, one of the reports is automatically igno= red by the client if their sequence numbers differ. So the outcome without = including the "identity if the node that sends realm report" is s= ame as

>The effect should be that the reacting node will= accept a realm report from anyone when there is no active OLR for the real= m but it will only listen to one reporting node when it has an active repor= t.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: dime@ietf.org
Subject: [Dime] DOIC issue #58 Proposal

 

All,

Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. 

Ulrich proposes one aspect of what is required in the issue description:
"In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report m= ore or less the same content, it cannot be expected that reports are 100% s= ynchronized. Especially sequence numbers may differ. To allow reacting node= s correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OL= Rs are extended to contain the Diameter Identity of the reporting node that= inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea= lm-routed-request type OLRs to answer messages MUST also insert their Diame= ter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order t= o detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report.  This would be an optional AVP only requ= ired for realm reports.  It would not be required for host reports as = the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state.&n= bsp; To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the real= m report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report.

Steve

___________________________________________________________=
______________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir des infor=
mations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. S=
i 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 alt=
ere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential o=
r privileged information that may be protected by law;

they should not be distributed, used or copied without auth=
orisation.


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.


_______________________________________________=
__________________________________________________________________________<=
/span>


 


Ce message et ses pieces jointes peuvent conten=
ir des informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans aut=
orisation. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pie=
ces jointes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce messa=
ge a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain co=
nfidential 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, pleas=
e 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.

 

--_000_A9CA33BB78081F478946E4F34BF9AAA018DDE42Bxmbrcdx10ciscoc_-- From nobody Mon Aug 4 15:01:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFC31A0350 for ; Mon, 4 Aug 2014 15:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n86rWiYecs80 for ; Mon, 4 Aug 2014 15:01:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10E21A034F for ; Mon, 4 Aug 2014 15:01:28 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s74M1MgL084874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 17:01:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Mon, 4 Aug 2014 17:01:21 -0500 X-Mao-Original-Outgoing-Id: 428882481.141651-12544345a7ce87198bd3a515e93348a0 Content-Transfer-Encoding: quoted-printable Message-Id: <1C7A057F-69D7-4A24-BDAC-7947F7058322@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBE0AB.4040505@usdonovans.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DOyAnIoZwP-aywG1vWEYzBNTpi4 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:01:32 -0000 On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) = wrote: > In this scenario, > > Now, assume that the realm report generators lose the ability to = communicate due to some localized failure. The realm is known to be = overloaded so realm reports need to be sent. Assume also that one of = the realm report generators thinks a 10% reduction is needed and a = second thinks a 50% reduction is needed. > =20 > Can you explain how did you come to this conclusion? > > One effect can be a thrashing between 10% reduction and 50% = reduction. > =20 > The client will ignore the report with lower sequence number and so I = don=92t see the thrashing between 10% and 50%. I think the example is a bit over simplified, in that you seem to assume = one 10% report and one 50% report. What you probably really have is a = series of reports from each source. I'm not talking about = re-transmissions of the same report, but reports with changes. For example, assume all of these are realm reports: source 1: seq 1 10% source 2: seq 2 50% source 1: seq 3: 11% source 2: seq 4: 55% source 1: seq 5: 0% source 2: seq 6: 45% This gives the sort of flapping that Steve referred to. Currently the = "source" part is not reported, so from the reacting node's perspective, = this is indistinguishable from the following: source 1: seq 1 10% source 1: seq 2 50% source 1: seq 3: 11% source 1: seq 4: 55% source 1: seq 5: 0% source 1: seq 6: 45% From nobody Mon Aug 4 15:18:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798B51A0350 for ; Mon, 4 Aug 2014 15:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqxz_GWKw1bK for ; Mon, 4 Aug 2014 15:18:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9341A037E for ; Mon, 4 Aug 2014 15:18:37 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s74MIZXI086202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 17:18:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> Date: Mon, 4 Aug 2014 17:18:34 -0500 X-Mao-Original-Outgoing-Id: 428883514.085645-1f08ad02006a7a54cddaddee2f896a9b Content-Transfer-Encoding: quoted-printable Message-Id: <80E1176F-9554-4587-A767-7F6D4256A2FA@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> <23820_1406943459_53DC40E3_23820_5125_1_fjij38s! 2deu48b76yvdkeun7.1406943453015@email.android.com> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NXqUdo7f25H-_8tvBmli_sQPIKk Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:18:48 -0000 On Aug 1, 2014, at 8:37 PM, lionel.morand@orange.com wrote: > In this scenario and other similar scenari, my requirement will be to = remove any host-based report and forward only realm-based reports. Any = host-based would be useless for clients beyond the agent. >=20 I agree the host report would be useless in this case. But what node do = you expect to remove it? The scenario Steve has in mind assumes the = topology-hiding node does not support DOIC in the first place, so how = would it know to remove an OLR? I agree with Steve that it is better to have the reacting node ignore a = report that it cannot act on, rather than misinterpret that report to = apply to the wrong thing. The former gives you a useless report, the = latter gives you a damaging report. Regardless of how we solve this, not solving it fails requirement 17 in = RFC 7068. > Regards, >=20 > Lionel >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > ---- Steve Donovan a =E9crit ---- >=20 >=20 > True. >=20 > So the question is, for this scenario, is it better for the client to > ignore the overload report - as determined by there being a difference > in the identity in the overload report and the identity in the > origin-host AVP - or for the client to apply the overload report to = all > traffic sent through the agent? >=20 > If we choose the latter then what happens when the client starts = seeing > overload reports from multiple servers behind the agent? >=20 > My instinct is that it is better for the client to ignore the report = as > not doing so could result in a significant reduction in overall = traffic > sent through the non DOIC, origin-host munging agent. >=20 > Steve >=20 > On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: >> But the client will never use the identity received in the OLR to = check which abatement to apply when sending a request to the server... = that is the agent from its point of view. >> Therefore the client will never apply the overload abatement. >>=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20 >> ---- Steve Donovan a =E9crit ---- >>=20 >>=20 >> For host reports, the client would always use the identity in the >> report, not the identity in the origin-host AVP. >>=20 >> Steve >>=20 >> On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >>> I understood! But what will be the use of this info by the client? = As for the client, the server is the identity of the Origin-host of the = received answer. >>>=20 >>> Lionel >>>=20 >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>=20 >>> ---- Steve Donovan a =E9crit ---- >>>=20 >>>=20 >>> Lionel, >>>=20 >>> The agent would not be inserting it's identity in the overload = report. >>> The proposal is that the DOIC node that inserted the overload report >>> includes its diameter identity in the overload report. As such, it >>> would be the server's identity that is in the overload report. >>>=20 >>> Sorry if I wasn't clear. >>>=20 >>> Steve >>>=20 >>> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>>=20 >>>> So the topology hiding is not a relevant example here. Even with an = identity inserted in the OLR, the client will never know to which server = the request is sent because the only relevant info for the client is the = Origin-host received in the answer i.e. the id of the agent. >>>>=20 >>>> Regards, >>>>=20 >>>> Lionel >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Envoy=E9 : vendredi 1 ao=FBt 2014 19:49 >>>> =C0 : MORAND Lionel IMT/OLN >>>> Cc : dime@ietf.org >>>> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC = issue #58 Proposal) >>>>=20 >>>> Lionel, >>>>=20 >>>> The issue is that there could be multiple/many servers behind the = agent >>>> that is changing the Origin-Host. If one of them is overloaded and >>>> generates a host report, clients will apply overload abatement to = all >>>> requests sent through that agent. The end result would be that the = non >>>> overloaded servers are under utilized. >>>>=20 >>>> Steve >>>>=20 >>>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>>> Hi Steve, >>>>>=20 >>>>> Not sure to understand. If an agent inserts its identity as = Origin-host in answers forwarded from servers, the client will see the = agent as the server. >>>>> What will be the added-value to add the identity of the server = inserting the OLR if the client will store this information along the = agent id? >>>>> Sorry if I've missed something... >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Lionel >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve = Donovan >>>>> Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 >>>>> Cc : dime@ietf.org >>>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) >>>>>=20 >>>>> Somewhat on on the path toward generalization, we have a second = issue >>>>> currently open that can be solved by having the DOIC node that = inserts >>>>> an overload report in an answer message include it's own diameter >>>>> identity in the overload report. >>>>>=20 >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >>>>>=20 >>>>> This issue points out that existing non DOIC agents are able to = change >>>>> the origin-host in answer messages. One example of where this is = done >>>>> is in topology hiding implementations. >>>>>=20 >>>>> This issue can be addressed through attribution of overload = reports. >>>>>=20 >>>>> As such, I propose that we add a required AVP to the OC-OLR group = AVP >>>>> that carries the diameter identity of the DOIC node that inserted = the >>>>> overload report into the answer message. Issue #66 points out the = need >>>>> in host reports and issue #58 points out the need in realm = reports. >>>>>=20 >>>>> Steve >>>>>=20 >>>>>=20 >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>>=20 >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson = wrote: >>>>>>=20 >>>>>>> I believe Nirav's view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>>>>>>=20 >>>>>>> Is seems like including the host name per Ulrich's suggestion is = a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>>>>>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>>>>>>=20 >>>>>>> -Dave >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>>>=20 >>>>>>> Hi Steve, >>>>>>>=20 >>>>>>> I agree with Nirav's view. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Lionel >>>>>>>=20 >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>=20 >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>>>=20 >>>>>>> Steve, >>>>>>>=20 >>>>>>> For this issue, I don't agree to include identity of the DOIC = node that sends the report, into the realm reports. >>>>>>>=20 >>>>>>> In my view, the issue mentioned below - of two agents not 100% = synchronize w.r.t the realm-report - is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>>>>>>=20 >>>>>>> Besides, I don't see any issue due to slight = miss-synchronization of the realm-reports between two agents since they = should still represent the realm load more or less accurately. >>>>>>>=20 >>>>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm = based on different values (for the same realm). So it does not matter if = the client does the same. >>>>>>>=20 >>>>>>> Finally, I don't see any value-add of using the "identity of the = node that sends the realm-report" to discard the other report related to = the same realm. In other words, this same logic can be achieved using = sequence-numbers as well, i.e. when the overload-report of an realm is = active, the client is going to ignore all the reports of the same realm = which has lower sequence number value. So in essence, when two agents = are sending realm-reports, one of the reports is automatically ignored = by the client if their sequence numbers differ. So the outcome without = including the "identity if the node that sends realm report" is same as >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>>=20 >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve = Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>>>=20 >>>>>>> Ulrich proposes one aspect of what is required in the issue = description: >>>>>>>=20 >>>>>>> "In deployments where more than one node is configured to take = the role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>>=20 >>>>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP = only required for realm reports. It would not be required for host = reports as the identity of the sender of the host report is implicitly = defined by the origin-host in the answer message. >>>>>>>=20 >>>>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>>>>>=20 >>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>>=20 >>>>>>> = __________________________________________________________________________= _______________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations confidentielles ou privilegiees et ne doivent donc >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si = vous avez recu ce message par erreur, veuillez le signaler >>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>>>>> they should not be distributed, used or copied without = authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>>> they should not be distributed, used or copied without = authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>>=20 >>>> = __________________________________________________________________________= _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>> they should not be distributed, used or copied without = authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >>=20 >=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Aug 4 15:32:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CBA1A038D for ; Mon, 4 Aug 2014 15:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14kxdPLDZRRJ for ; Mon, 4 Aug 2014 15:32:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C758C1A0387 for ; Mon, 4 Aug 2014 15:32:12 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s74MW6LR087225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 17:32:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> Date: Mon, 4 Aug 2014 17:32:05 -0500 X-Mao-Original-Outgoing-Id: 428884325.609516-4b31b9a991c4a75794a80408bba4328f Content-Transfer-Encoding: quoted-printable Message-Id: <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> To: "Shishufeng (Susan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bCEHkBkvEn_qsiPrdnfsUn05dzY Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:32:15 -0000 Let me try to rephrase the problem: Consider the following scenario: S1 / C---P--S2 \ S3 "P" is a diameter proxy that does _not_ support DOIC, and performs = topology hiding. The client and servers do support DOIC.=20 Assume S1 becomes overloaded. It sends an host OLR with a reduction = percentage of 100% in an answer to a request sent by C. The answer has = an Origin-Host of "S1". P receives the answer, and changes Origin-Host to "P". Since P does not = support DOIC, it treats the OLR as an "unknown AVP", and forwards it = unchanged. C receives the report, and and entirely stops sending traffic to P. (As = far as C knows, P is the server.)=20 This is not the desired behavior. RFC7068 Req 17 says the following. The = behavior in this example clearly violates the MUST NOT: > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. >=20 If, on the other hand, the OLR internally identified the overloaded node = as "S1", C would at least know that it can't do anything useful with the = OLR, since it doesn't know about S1 due to the topology hiding at P. In = this case, it just ignores the OLR. That still violates the SHOULD, but = at least does not violate the MUST NOT. On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) = wrote: > Hello, >=20 > I really don't understand the logic for the host to insert its own = identity into the overload report. Wouldn't it be the host to report its = own overload report in an answer message to the client? Why we need the = agent to do anything in this case? >=20 > To say the least, if the host can insert its identity into the = message, what's the benefit to have the agent for topology hiding? >=20 > Best Regards, > Susan >=20 > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 > Sent: Saturday, August 02, 2014 3:54 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC = issue #58 Proposal) >=20 > Yes, it could be either. The critical point is that the overloaded = host is indicated by the diameter id in the overload report, not the = origin-host AVP. >=20 > Steve >=20 > On 8/1/14, 2:02 PM, Ben Campbell wrote: >> I don't think you can conflate "host that generated this OLR" with=20 >> "host that is overloaded". It's perfectly valid for them to not be = the=20 >> same thing, even for host reports. (But I'd be happy to include=20 >> both.) >>=20 >> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>=20 >>> Somewhat on on the path toward generalization, we have a second = issue currently open that can be solved by having the DOIC node that = inserts an overload report in an answer message include it's own = diameter identity in the overload report. >>>=20 >>> I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >>>=20 >>> This issue points out that existing non DOIC agents are able to = change the origin-host in answer messages. One example of where this is = done is in topology hiding implementations. >>>=20 >>> This issue can be addressed through attribution of overload reports. >>>=20 >>> As such, I propose that we add a required AVP to the OC-OLR group = AVP that carries the diameter identity of the DOIC node that inserted = the overload report into the answer message. Issue #66 points out the = need in host reports and issue #58 points out the need in realm reports. >>>=20 >>> Steve >>>=20 >>>=20 >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>>=20 >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson = wrote: >>>>=20 >>>>> I believe Nirav's view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>>>> Is seems like including the host name per Ulrich's suggestion is = a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>>>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>>>> -Dave >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>> lionel.morand@orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>> Hi Steve, >>>>> I agree with Nirav's view. >>>>> Regards, >>>>> Lionel >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>> Steve, >>>>> For this issue, I don't agree to include identity of the DOIC = node that sends the report, into the realm reports. >>>>> In my view, the issue mentioned below - of two agents not 100% = synchronize w.r.t the realm-report - is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>>>> Besides, I don't see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still = represent the realm load more or less accurately. >>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm = based on different values (for the same realm). So it does not matter if = the client does the same. >>>>> Finally, I don't see any value-add of using the "identity of the=20= >>>>> node that sends the realm-report" to discard the other report=20 >>>>> related to the same realm. In other words, this same logic can be=20= >>>>> achieved using sequence-numbers as well, i.e. when the=20 >>>>> overload-report of an realm is active, the client is going to=20 >>>>> ignore all the reports of the same realm which has lower sequence=20= >>>>> number value. So in essence, when two agents are sending=20 >>>>> realm-reports, one of the reports is automatically ignored by the=20= >>>>> client if their sequence numbers differ. So the outcome without=20 >>>>> including the "identity if the node that sends realm report" is=20 >>>>> same as >>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>> Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>> All, >>>>>=20 >>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>=20 >>>>> Ulrich proposes one aspect of what is required in the issue = description: >>>>>=20 >>>>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>=20 >>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP = only required for realm reports. It would not be required for host = reports as the identity of the sender of the host report is implicitly = defined by the origin-host in the answer message. >>>>>=20 >>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>>>=20 >>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>=20 >>>>> Steve >>>>>=20 >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>> informations confidentielles ou privilegiees et ne doivent donc = pas=20 >>>>> etre diffuses, exploites ou copies sans autorisation. Si vous avez=20= >>>>> 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=20 >>>>> 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. >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Aug 4 15:41:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50C21A038F for ; Mon, 4 Aug 2014 15:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ36jMPDuMtj for ; Mon, 4 Aug 2014 15:41:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E531A038D for ; Mon, 4 Aug 2014 15:41:23 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s74MfHRw087973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 17:41:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Mon, 4 Aug 2014 17:41:16 -0500 X-Mao-Original-Outgoing-Id: 428884876.656837-4e9bd72c0c6412524d59d73752963dec Content-Transfer-Encoding: quoted-printable Message-Id: <2335170D-0C0D-4D2D-8EED-63B10B019F09@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> <53DC6449.6030! 905@usdonovans.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PtS7c2OT7QOCvum5ZFIEvlNzv6g Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:41:28 -0000 On Aug 3, 2014, at 11:45 PM, Nirav Salot (nsalot) = wrote: > Steve, >=20 > How would topology hiding is achieved if the OLR has host's identity? Is your concern that we would leak server identity across the topology = hiding proxy? This could be a valid concern in some scenarios. Can you = suggest a solution that would not leak that information? > So the solution in this case is to turn-off the topology hiding = feature at the agent so that the client receives identity of the host in = the Origin-Host and applies abatement accordingly. I sincerely doubt an operator is going to be willing to accept that. > The other solution is to turn-off the generation of OLR at the host = since the agents - which are supposed to consume the host's OLR in the = topology hiding case - are not upgraded to support DOIC (i.e. are non = DOIC agent yet). We have a SHOULD level requirement (req 34) to be able to operate across = non-supporting agents. Given that it's a SHOULD, not a MUST, it might be = acceptable to only partially meet the requirement (for example, restrict = it to non-topology-hiding agents.) >=20 > I don't see inclusion of host's identity in the OLR as the solution = for the problem - i.e. when the non DOIC agent is doing topology hiding = - we are trying to solve here. Including the host identity solves the problem of having the client = perform abatement on all traffic going to the proxy, when that was not = the intent of the OLR. (I demonstrated that in my reply to Susan.) Do = you disagree that it accomplish that? If so, then where does it fail? I agree that including the host identity might leak information that the = topology hiding was intended to hide. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Saturday, August 02, 2014 9:39 AM > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC = issue #58 Proposal) >=20 > The issue is that the agent in question is a non DOIC agent. This is = a backwards compatibility issue. >=20 > Steve >=20 >=20 > On 8/1/14, 8:37 PM, lionel.morand@orange.com wrote: >> In this scenario and other similar scenari, my requirement will be to = remove any host-based report and forward only realm-based reports. Any = host-based would be useless for clients beyond the agent. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20 >> ---- Steve Donovan a =E9crit ---- >>=20 >>=20 >> True. >>=20 >> So the question is, for this scenario, is it better for the client to=20= >> ignore the overload report - as determined by there being a = difference=20 >> in the identity in the overload report and the identity in the=20 >> origin-host AVP - or for the client to apply the overload report to=20= >> all traffic sent through the agent? >>=20 >> If we choose the latter then what happens when the client starts=20 >> seeing overload reports from multiple servers behind the agent? >>=20 >> My instinct is that it is better for the client to ignore the report=20= >> as not doing so could result in a significant reduction in overall=20 >> traffic sent through the non DOIC, origin-host munging agent. >>=20 >> Steve >>=20 >> On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: >>> But the client will never use the identity received in the OLR to = check which abatement to apply when sending a request to the server... = that is the agent from its point of view. >>> Therefore the client will never apply the overload abatement. >>>=20 >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>=20 >>> ---- Steve Donovan a =E9crit ---- >>>=20 >>>=20 >>> For host reports, the client would always use the identity in the=20 >>> report, not the identity in the origin-host AVP. >>>=20 >>> Steve >>>=20 >>> On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >>>> I understood! But what will be the use of this info by the client? = As for the client, the server is the identity of the Origin-host of the = received answer. >>>>=20 >>>> Lionel >>>>=20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>=20 >>>> ---- Steve Donovan a =E9crit ---- >>>>=20 >>>>=20 >>>> Lionel, >>>>=20 >>>> The agent would not be inserting it's identity in the overload = report. >>>> The proposal is that the DOIC node that inserted the overload = report=20 >>>> includes its diameter identity in the overload report. As such, it=20= >>>> would be the server's identity that is in the overload report. >>>>=20 >>>> Sorry if I wasn't clear. >>>>=20 >>>> Steve >>>>=20 >>>> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>>>> Hi Steve, >>>>>=20 >>>>> So the topology hiding is not a relevant example here. Even with = an identity inserted in the OLR, the client will never know to which = server the request is sent because the only relevant info for the client = is the Origin-host received in the answer i.e. the id of the agent. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Lionel >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 :=20 >>>>> vendredi 1 ao=FBt 2014 19:49 =C0 : MORAND Lionel IMT/OLN Cc :=20 >>>>> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports=20= >>>>> (was Re: DOIC issue #58 Proposal) >>>>>=20 >>>>> Lionel, >>>>>=20 >>>>> The issue is that there could be multiple/many servers behind the=20= >>>>> agent that is changing the Origin-Host. If one of them is=20 >>>>> overloaded and generates a host report, clients will apply = overload=20 >>>>> abatement to all requests sent through that agent. The end result=20= >>>>> would be that the non overloaded servers are under utilized. >>>>>=20 >>>>> Steve >>>>>=20 >>>>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>>>> Hi Steve, >>>>>>=20 >>>>>> Not sure to understand. If an agent inserts its identity as = Origin-host in answers forwarded from servers, the client will see the = agent as the server. >>>>>> What will be the added-value to add the identity of the server = inserting the OLR if the client will store this information along the = agent id? >>>>>> Sorry if I've missed something... >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Lionel >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve=20 >>>>>> Donovan Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 Cc : = dime@ietf.org=20 >>>>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC = issue=20 >>>>>> #58 Proposal) >>>>>>=20 >>>>>> Somewhat on on the path toward generalization, we have a second=20= >>>>>> issue currently open that can be solved by having the DOIC node=20= >>>>>> that inserts an overload report in an answer message include it's=20= >>>>>> own diameter identity in the overload report. >>>>>>=20 >>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >>>>>>=20 >>>>>> This issue points out that existing non DOIC agents are able to=20= >>>>>> change the origin-host in answer messages. One example of where=20= >>>>>> this is done is in topology hiding implementations. >>>>>>=20 >>>>>> This issue can be addressed through attribution of overload = reports. >>>>>>=20 >>>>>> As such, I propose that we add a required AVP to the OC-OLR group=20= >>>>>> AVP that carries the diameter identity of the DOIC node that=20 >>>>>> inserted the overload report into the answer message. Issue #66=20= >>>>>> points out the need in host reports and issue #58 points out the = need in realm reports. >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>>=20 >>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>> +1 (modulo my comment to generalize) >>>>>>>=20 >>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson = wrote: >>>>>>>=20 >>>>>>>> I believe Nirav's view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>>>>>>>=20 >>>>>>>> Is seems like including the host name per Ulrich's suggestion = is a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>>>>>>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>>>>>>>=20 >>>>>>>> -Dave >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>> lionel.morand@orange.com >>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>>>>=20 >>>>>>>> Hi Steve, >>>>>>>>=20 >>>>>>>> I agree with Nirav's view. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Lionel >>>>>>>>=20 >>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>>=20 >>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>>>>=20 >>>>>>>> Steve, >>>>>>>>=20 >>>>>>>> For this issue, I don't agree to include identity of the DOIC = node that sends the report, into the realm reports. >>>>>>>>=20 >>>>>>>> In my view, the issue mentioned below - of two agents not 100% = synchronize w.r.t the realm-report - is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>>>>>>>=20 >>>>>>>> Besides, I don't see any issue due to slight = miss-synchronization of the realm-reports between two agents since they = should still represent the realm load more or less accurately. >>>>>>>>=20 >>>>>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm = based on different values (for the same realm). So it does not matter if = the client does the same. >>>>>>>>=20 >>>>>>>> Finally, I don't see any value-add of using the "identity of = the=20 >>>>>>>> node that sends the realm-report" to discard the other report=20= >>>>>>>> related to the same realm. In other words, this same logic can=20= >>>>>>>> be achieved using sequence-numbers as well, i.e. when the=20 >>>>>>>> overload-report of an realm is active, the client is going to=20= >>>>>>>> ignore all the reports of the same realm which has lower=20 >>>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>>> ignored by the client if their sequence numbers differ. So the=20= >>>>>>>> outcome without including the "identity if the node that sends=20= >>>>>>>> realm report" is same as >>>>>>>>> The effect should be that the reacting node will accept a = realm report from anyone when there is no active OLR for the realm but = it will only listen to one reporting node when it has an active report. >>>>>>>> Regards, >>>>>>>> Nirav. >>>>>>>>=20 >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>>>> Donovan >>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> Issue #58 deals with the fact that there can be multiple = senders of realm overload report for the same realm. >>>>>>>>=20 >>>>>>>> Ulrich proposes one aspect of what is required in the issue = description: >>>>>>>>=20 >>>>>>>> "In deployments where more than one node is configured to take = the role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>>>=20 >>>>>>>> I agree with Ulrich that realm reports must include the = identity of the DOIC node that sends the report. This would be an = optional AVP only required for realm reports. It would not be required = for host reports as the identity of the sender of the host report is = implicitly defined by the origin-host in the answer message. >>>>>>>>=20 >>>>>>>> I also agree that the Diameter Identity of the reporting node = be used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>>>>>>=20 >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>>>=20 >>>>>>>> Steve >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ________________________________________________________________ >>>>>>>> _________________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20= >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or=20 >>>>>>>> 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. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> = __________________________________________________________________ >>>>>> _______________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations=20 >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu=20 >>>>>> 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. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>> = ___________________________________________________________________ >>>>> ______________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20= >>>>> 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. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>> = ____________________________________________________________________ >>>> _____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20= >>>> 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. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> 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. >>>>=20 >>>>=20 >>>=20 >>> = _____________________________________________________________________ >>> ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >>> 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. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> 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. >>>=20 >>>=20 >>=20 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >>=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 nobody Mon Aug 4 19:15:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13D51A0BE8 for ; Mon, 4 Aug 2014 19:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bH4bEMGMFGo for ; Mon, 4 Aug 2014 19:15:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1151A0B00 for ; Mon, 4 Aug 2014 19:15:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHX35249; Tue, 05 Aug 2014 02:15:34 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Aug 2014 03:15:33 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Tue, 5 Aug 2014 10:15:24 +0800 From: "Shishufeng (Susan)" To: Ben Campbell , "Nirav Salot (nsalot)" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPsDP2chukSEA/nkysm3WzrS0HkpvBQ+RQ Date: Tue, 5 Aug 2014 02:15:23 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF62069@SZXEMA512-MBX.china.huawei.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBE0AB.4040505@usdonovans.com> <1C7A057F-69D7-4A24-BDAC-7947F7058322@nostrum.com> In-Reply-To: <1C7A057F-69D7-4A24-BDAC-7947F7058322@nostrum.com> Accept-Language: en-GB, 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NKXZT2vuLn2RbxuXjqJ6HeNvkPg Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 02:15:40 -0000 Hello Ben, I don't understand how the overload report of the same realm in a short per= iod can have such big jump between each other. My understanding is that the= overload of the realm should be almost the same to all the agents having t= he full view of the realm, though there might be little difference which ha= s minor impact on overload control. Best Regards, Susan -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, August 05, 2014 6:01 AM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: Re: [Dime] DOIC issue #58 Proposal On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) wrote: > In this scenario, > > Now, assume that the realm report generators lose the ability to commun= icate due to some localized failure. The realm is known to be overloaded s= o realm reports need to be sent. Assume also that one of the realm report = generators thinks a 10% reduction is needed and a second thinks a 50% reduc= tion is needed. > =20 > Can you explain how did you come to this conclusion? > > One effect can be a thrashing between 10% reduction and 50% reduction. > =20 > The client will ignore the report with lower sequence number and so I don= 't see the thrashing between 10% and 50%. I think the example is a bit over simplified, in that you seem to assume on= e 10% report and one 50% report. What you probably really have is a series = of reports from each source. I'm not talking about re-transmissions of the = same report, but reports with changes. For example, assume all of these are realm reports: source 1: seq 1 10% source 2: seq 2 50% source 1: seq 3: 11% source 2: seq 4: 55% source 1: seq 5: 0% source 2: seq 6: 45% This gives the sort of flapping that Steve referred to. Currently the "sour= ce" part is not reported, so from the reacting node's perspective, this is = indistinguishable from the following: source 1: seq 1 10% source 1: seq 2 50% source 1: seq 3: 11% source 1: seq 4: 55% source 1: seq 5: 0% source 1: seq 6: 45% From nobody Mon Aug 4 19:35:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA041ABB32 for ; Mon, 4 Aug 2014 19:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIdrW6yeYsL7 for ; Mon, 4 Aug 2014 19:35:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA161ABB27 for ; Mon, 4 Aug 2014 19:35:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHX36264; Tue, 05 Aug 2014 02:35:41 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Aug 2014 03:35:40 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Tue, 5 Aug 2014 10:35:31 +0800 From: "Shishufeng (Susan)" To: Ben Campbell Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPrccW68dF5OCezEe+7yNvYXl1rJu8qNhggAPdU4CAAMbBIA== Date: Tue, 5 Aug 2014 02:35:30 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> In-Reply-To: <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> Accept-Language: en-GB, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Mf195XpklZnj6b5XIs7_qbJvXDE Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 02:35:47 -0000 Hello Ben, Putting S1 node in the OLR would break the principle of topology hiding. If= this is what the operator could accept, what's the benefit to have the age= nt on the route to do the topology hiding? >From my point of view, there are other ways to solve the problem: - If the hosts behind the agent can be enhanced to support overload control= , the agent should be enhanced to support overload control, or be enhanced = to just discard the OLR AVP. - Or by configuration disable the topology hiding functionality of the agen= t since it does not make sense if the S1 could indicate its node identity t= o the client in the OLR. - Or by configuration, the hosts behind the agent should know that the agen= t does not support overload control, then don't send OLR to the client. Best Regards, Susan -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, August 05, 2014 6:32 AM To: Shishufeng (Susan) Cc: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Let me try to rephrase the problem: Consider the following scenario: S1 / C---P--S2 \ S3 "P" is a diameter proxy that does _not_ support DOIC, and performs topology= hiding. The client and servers do support DOIC.=20 Assume S1 becomes overloaded. It sends an host OLR with a reduction percent= age of 100% in an answer to a request sent by C. The answer has an Origin-H= ost of "S1". P receives the answer, and changes Origin-Host to "P". Since P does not sup= port DOIC, it treats the OLR as an "unknown AVP", and forwards it unchanged= . C receives the report, and and entirely stops sending traffic to P. (As far= as C knows, P is the server.)=20 This is not the desired behavior. RFC7068 Req 17 says the following. The be= havior in this example clearly violates the MUST NOT: > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. >=20 If, on the other hand, the OLR internally identified the overloaded node as= "S1", C would at least know that it can't do anything useful with the OLR,= since it doesn't know about S1 due to the topology hiding at P. In this ca= se, it just ignores the OLR. That still violates the SHOULD, but at least d= oes not violate the MUST NOT. On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > Hello, >=20 > I really don't understand the logic for the host to insert its own identi= ty into the overload report. Wouldn't it be the host to report its own over= load report in an answer message to the client? Why we need the agent to do= anything in this case? >=20 > To say the least, if the host can insert its identity into the message, w= hat's the benefit to have the agent for topology hiding? >=20 > Best Regards, > Susan >=20 > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Saturday, August 02, 2014 3:54 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) >=20 > Yes, it could be either. The critical point is that the overloaded host = is indicated by the diameter id in the overload report, not the origin-host= AVP. >=20 > Steve >=20 > On 8/1/14, 2:02 PM, Ben Campbell wrote: >> I don't think you can conflate "host that generated this OLR" with=20 >> "host that is overloaded". It's perfectly valid for them to not be=20 >> the same thing, even for host reports. (But I'd be happy to include >> both.) >>=20 >> On Aug 1, 2014, at 11:09 AM, Steve Donovan wr= ote: >>=20 >>> Somewhat on on the path toward generalization, we have a second issue c= urrently open that can be solved by having the DOIC node that inserts an ov= erload report in an answer message include it's own diameter identity in th= e overload report. >>>=20 >>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Ho= st. >>>=20 >>> This issue points out that existing non DOIC agents are able to change = the origin-host in answer messages. One example of where this is done is i= n topology hiding implementations. >>>=20 >>> This issue can be addressed through attribution of overload reports. >>>=20 >>> As such, I propose that we add a required AVP to the OC-OLR group AVP t= hat carries the diameter identity of the DOIC node that inserted the overlo= ad report into the answer message. Issue #66 points out the need in host r= eports and issue #58 points out the need in realm reports. >>>=20 >>> Steve >>>=20 >>>=20 >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>>=20 >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>=20 >>>>> I believe Nirav's view requires all hosts in a realm to be the same v= endor and use a proprietary communication protocol to synchronize the host = report. Or, if a multiple (redundant or active-active) load-balancing agent= s are generating the report, they must similarly be synchronized. >>>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>>> In some applications, the hosts can be completely decoupled (agnostic= about each other). I think it would be poor to add a synchronization requi= rement just to support DOIC. >>>>> -Dave >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>> lionel.morand@orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>> with Nirav's view. >>>>> Regards, >>>>> Lionel >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I= =20 >>>>> don't agree to include identity of the DOIC node that sends the repor= t, into the realm reports. >>>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>>> Finally, I don't see any value-add of using the "identity of the=20 >>>>> node that sends the realm-report" to discard the other report=20 >>>>> related to the same realm. In other words, this same logic can be=20 >>>>> achieved using sequence-numbers as well, i.e. when the=20 >>>>> overload-report of an realm is active, the client is going to=20 >>>>> ignore all the reports of the same realm which has lower sequence=20 >>>>> number value. So in essence, when two agents are sending=20 >>>>> realm-reports, one of the reports is automatically ignored by the=20 >>>>> client if their sequence numbers differ. So the outcome without=20 >>>>> including the "identity if the node that sends realm report" is=20 >>>>> same as >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>> Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>=20 >>>>> Issue #58 deals with the fact that there can be multiple senders of r= ealm overload report for the same realm. >>>>>=20 >>>>> Ulrich proposes one aspect of what is required in the issue descripti= on: >>>>>=20 >>>>> "In deployments where more than one node is configured to take the ro= le of a reporting node for realm-routed-request reports, reacting nodes may= receive in different answer messages different realm-routed-request type O= LRs inserted by the different reporting nodes. Although it is expected that= the different reporting nodes report more or less the same content, it can= not be expected that reports are 100% synchronized. Especially sequence num= bers may differ. To allow reacting nodes correctly detect outdates/replays/= freshness of OLRs in this scenario, it is proposed that realm-routed-reques= t type OLRs are extended to contain the Diameter Identity of the reporting = node that inserted the realm-routed-request type OLR. (e.g. as already prop= osed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their Di= ameter Identity. Reacting nodes MUST take the Diameter Identity received wi= thin the OLR into account in order to detect outdates/replays/freshness." >>>>>=20 >>>>> I agree with Ulrich that realm reports must include the identity of t= he DOIC node that sends the report. This would be an optional AVP only req= uired for realm reports. It would not be required for host reports as the = identity of the sender of the host report is implicitly defined by the orig= in-host in the answer message. >>>>>=20 >>>>> I also agree that the Diameter Identity of the reporting node be used= to determine if a received report is ignored or used to update existing st= ate. To this end I propose that we add wording that for the duration of a = realm report, the reacting node only listens for updates to the realm repor= t from from the DOIC node that sent the realm report that resulted in the r= ealm OCS being stored. >>>>>=20 >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>>>=20 >>>>> Steve >>>>>=20 >>>>>=20 >>>>> __________________________________________________________________ >>>>> _______________________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur = et le detruire ainsi que les pieces jointes. Les messages electroniques eta= nt susceptibles d'alteration, Orange decline toute responsabilite si ce mes= sage a ete altere, deforme ou falsifie. Merci. >>>>> This message and its attachments may contain confidential or=20 >>>>> 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 an= d 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. >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Aug 4 21:38:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0802B1B2834 for ; Mon, 4 Aug 2014 21:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4YFG42HmSQv for ; Mon, 4 Aug 2014 21:38:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578411B2831 for ; Mon, 4 Aug 2014 21:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3348; q=dns/txt; s=iport; t=1407213515; x=1408423115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nI+ZFgj/fp+BYw1V89zo8PHeLtBVMIUlAwsxDEyXLY8=; b=QpAKpORLMLND+UVxpYYpADGqBzNz24r1OxQrIhnU9dnh+QPR4aZk3PLa 4uatcyFJCa6g48Kugl2p+QCHSCw1ZFEZxocYd6Zimbnr+fV9dQYtbDCt0 4lLXbKeph9NBvFzB7MfImf4G0yyTwmduiLoTMfC2PRz/PspamOKC2WUQC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAEpf4FOtJA2L/2dsb2JhbABbgw2BKQTTTQGBGRZ3hAMBAQEDATo/BQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIiDIIxCYXjxsxBwaDKYEcAQSwaIFcbAGBBGyBRg X-IronPort-AV: E=Sophos;i="5.01,802,1400025600"; d="scan'208";a="66543431" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 05 Aug 2014 04:38:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s754cYkQ005582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 04:38:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 23:38:34 -0500 From: "Nirav Salot (nsalot)" To: "Shishufeng (Susan)" , Ben Campbell Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrPj5lwrN9479MEmgKHB41eF0/5u7N7ZAgACxMQCAAECkAIAAEyqA//+uAICAAIEngIADeSbwgAF0HYCAAEb6gP//0N+g Date: Tue, 5 Aug 2014 04:38:33 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBE0AB.4040505@usdonovans.com> <1C7A057F-69D7-4A24-BDAC-7947F7058322@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62069@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF62069@SZXEMA512-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7dJ6mazCW9xJHsyvkH6TPgrjwQ8 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:38:40 -0000 On top of what Susan mentioned below, Ben's example assumes that the realm-= reports are out of sync but the sequence numbers are magically synchronized= such that each report (from different nodes) has monotonously increasing s= equence number. Besides, we are trying to solve non-issue here - that of "how to make the c= lient ignore one of the realm-report when the two reports have big differen= ce between them". Shouldn't the system administrator (and the operator) need to worry about f= ixing the main issue here? Finally, I don't see any issue if a client sees two reports with big jump i= n their values. This may be very normal case (or as corner case as we are discussing here o= f two report generating nodes out-of-sync with each other), e.g. when the c= lient receives 10% report (host/realm) and then there is no communication b= etween the client and the report generator while the report changes from 10= % to 50%. So the client needs to anyway handle this.=20 Regards, Nirav. -----Original Message----- From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]=20 Sent: Tuesday, August 05, 2014 7:45 AM To: Ben Campbell; Nirav Salot (nsalot) Cc: dime@ietf.org Subject: RE: [Dime] DOIC issue #58 Proposal Hello Ben, I don't understand how the overload report of the same realm in a short per= iod can have such big jump between each other. My understanding is that the= overload of the realm should be almost the same to all the agents having t= he full view of the realm, though there might be little difference which ha= s minor impact on overload control. Best Regards, Susan -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, August 05, 2014 6:01 AM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: Re: [Dime] DOIC issue #58 Proposal On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) wrote: > In this scenario, > > Now, assume that the realm report generators lose the ability to commun= icate due to some localized failure. The realm is known to be overloaded s= o realm reports need to be sent. Assume also that one of the realm report = generators thinks a 10% reduction is needed and a second thinks a 50% reduc= tion is needed. > =20 > Can you explain how did you come to this conclusion? > > One effect can be a thrashing between 10% reduction and 50% reduction. > =20 > The client will ignore the report with lower sequence number and so I don= 't see the thrashing between 10% and 50%. I think the example is a bit over simplified, in that you seem to assume on= e 10% report and one 50% report. What you probably really have is a series = of reports from each source. I'm not talking about re-transmissions of the = same report, but reports with changes. For example, assume all of these are realm reports: source 1: seq 1 10% source 2: seq 2 50% source 1: seq 3: 11% source 2: seq 4: 55% source 1: seq 5: 0% source 2: seq 6: 45% This gives the sort of flapping that Steve referred to. Currently the "sour= ce" part is not reported, so from the reacting node's perspective, this is = indistinguishable from the following: source 1: seq 1 10% source 1: seq 2 50% source 1: seq 3: 11% source 1: seq 4: 55% source 1: seq 5: 0% source 1: seq 6: 45% From nobody Mon Aug 4 21:53:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E101B28AF for ; Mon, 4 Aug 2014 21:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeGE8OG4qMEG for ; Mon, 4 Aug 2014 21:53:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9011F1B28A8 for ; Mon, 4 Aug 2014 21:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22487; q=dns/txt; s=iport; t=1407214394; x=1408423994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pwdNP70Alj/bK413IDVelrusfUNLhwqRzsgWs+XbV5A=; b=SWxDx4Edy+p80w/x1QRU15fBbvpnjbDOv0gaVgpq1TE5mq4z8aC1kP/r OWYTmsW20Bk4Lf9r/wHSTcsumn/PEavt8Bn+F68+FsCuAzwdkBgi5McVp Rn+Wqbw1nA7o+h8OX7zad/PH2ipgPVREmA2/uAdUufPHkbjMRR8LtaIyA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAAtj4FOtJV2P/2dsb2JhbABSCYMNUlcEy3kKh0oBgRoWd4QDAQEBAwEBAQEXTQcFBgUHBAIBCBEEAQEBCgsSBycLFAkIAgQOBQgTiB8IDcQTEwSMCoJgBwoBDhExBwYEgyWBHAWKVY0ImQuDTWyBBgcXIg X-IronPort-AV: E=Sophos;i="5.01,802,1400025600"; d="scan'208";a="345128793" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2014 04:53:13 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s754rCeD008417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 04:53:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 23:53:12 -0500 From: "Nirav Salot (nsalot)" To: Ben Campbell Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8QG4AgAAZ2YCAAAW4gIAABbIAgAAESwCAAAOAgIAAJFYAgAAP7wCAADt4gIAAKjWAgALZK9CAAYJZAIAAErqQ Date: Tue, 5 Aug 2014 04:53:11 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <12647_1406909788_53DBBD5C_12647_11123_1_6B7134B31289DC4FAF731D844122B36E687F6F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBD309.4000704@usdonovans.com> <11715_1406916566_53DBD7D6_11715_11496_1_6B7134B31289DC4FAF731D844122B36E68838C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <53DBDC9C.2040703@usdonovans.com> <24690_1406918711_53DBE037_24690_2977_1_y13mk2t6qg7tkiii4a7pivr6.1406918707880@email.android.com>, <53DBE325.1040505@usdonovans.com> <6818_1406927265_53DC01A1_6818_5561_1_q7v3q29xx0f5oapnw9bisq9r.1406927260787@email.android.com>, <53DC0EFE.9020601@usdonovans.com> <23820_1406943459_53DC40E3_23820_5125_1_fjij38s2deu48b76yvdkeun7.1406943453015@email.android.com> <53DC6449.6030! 905@usdonovans.com> <2335170D-0C0D-4D2D-8EED-63B10B019F09@nostrum.com> In-Reply-To: <2335170D-0C0D-4D2D-8EED-63B10B019F09@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hgTvQyPJbVZiQS1lBrib5zBc8Og Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:53:18 -0000 Ben, For my proposal > The other solution is to turn-off the generation of OLR at the host since= the agents - which are supposed to consume the host's OLR in the topology = hiding case - are not upgraded to support DOIC (i.e. are non DOIC agent yet= ). You have an objection considering req 34. And hence your proposal is > I agree with Steve that it is better to have the reacting node ignore a r= eport that it cannot act on, rather than misinterpret that report to apply = to the wrong thing. The former gives you a useless report, the latter gives= you a damaging report. What is the difference in the outcome between "host does not generate overl= oad report" v/s "host generates overload report and the reacting MUST ignor= e it"? Regards, Nirav. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, August 05, 2014 4:11 AM To: Nirav Salot (nsalot) Cc: Steve Donovan; lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) On Aug 3, 2014, at 11:45 PM, Nirav Salot (nsalot) wrote: > Steve, >=20 > How would topology hiding is achieved if the OLR has host's identity? Is your concern that we would leak server identity across the topology hidi= ng proxy? This could be a valid concern in some scenarios. Can you suggest = a solution that would not leak that information? > So the solution in this case is to turn-off the topology hiding feature a= t the agent so that the client receives identity of the host in the Origin-= Host and applies abatement accordingly. I sincerely doubt an operator is going to be willing to accept that. > The other solution is to turn-off the generation of OLR at the host since= the agents - which are supposed to consume the host's OLR in the topology = hiding case - are not upgraded to support DOIC (i.e. are non DOIC agent yet= ). We have a SHOULD level requirement (req 34) to be able to operate across no= n-supporting agents. Given that it's a SHOULD, not a MUST, it might be acce= ptable to only partially meet the requirement (for example, restrict it to = non-topology-hiding agents.) >=20 > I don't see inclusion of host's identity in the OLR as the solution for t= he problem - i.e. when the non DOIC agent is doing topology hiding - we are= trying to solve here. Including the host identity solves the problem of having the client perform= abatement on all traffic going to the proxy, when that was not the intent = of the OLR. (I demonstrated that in my reply to Susan.) Do you disagree tha= t it accomplish that? If so, then where does it fail? I agree that including the host identity might leak information that the to= pology hiding was intended to hide. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Saturday, August 02, 2014 9:39 AM > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) >=20 > The issue is that the agent in question is a non DOIC agent. This is a b= ackwards compatibility issue. >=20 > Steve >=20 >=20 > On 8/1/14, 8:37 PM, lionel.morand@orange.com wrote: >> In this scenario and other similar scenari, my requirement will be to re= move any host-based report and forward only realm-based reports. Any host-b= ased would be useless for clients beyond the agent. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20 >> ---- Steve Donovan a =E9crit ---- >>=20 >>=20 >> True. >>=20 >> So the question is, for this scenario, is it better for the client to=20 >> ignore the overload report - as determined by there being a=20 >> difference in the identity in the overload report and the identity in=20 >> the origin-host AVP - or for the client to apply the overload report=20 >> to all traffic sent through the agent? >>=20 >> If we choose the latter then what happens when the client starts=20 >> seeing overload reports from multiple servers behind the agent? >>=20 >> My instinct is that it is better for the client to ignore the report=20 >> as not doing so could result in a significant reduction in overall=20 >> traffic sent through the non DOIC, origin-host munging agent. >>=20 >> Steve >>=20 >> On 8/1/14, 4:07 PM, lionel.morand@orange.com wrote: >>> But the client will never use the identity received in the OLR to check= which abatement to apply when sending a request to the server... that is t= he agent from its point of view. >>> Therefore the client will never apply the overload abatement. >>>=20 >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>=20 >>> ---- Steve Donovan a =E9crit ---- >>>=20 >>>=20 >>> For host reports, the client would always use the identity in the=20 >>> report, not the identity in the origin-host AVP. >>>=20 >>> Steve >>>=20 >>> On 8/1/14, 1:45 PM, lionel.morand@orange.com wrote: >>>> I understood! But what will be the use of this info by the client? As = for the client, the server is the identity of the Origin-host of the receiv= ed answer. >>>>=20 >>>> Lionel >>>>=20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>=20 >>>> ---- Steve Donovan a =E9crit ---- >>>>=20 >>>>=20 >>>> Lionel, >>>>=20 >>>> The agent would not be inserting it's identity in the overload report. >>>> The proposal is that the DOIC node that inserted the overload=20 >>>> report includes its diameter identity in the overload report. As=20 >>>> such, it would be the server's identity that is in the overload report= . >>>>=20 >>>> Sorry if I wasn't clear. >>>>=20 >>>> Steve >>>>=20 >>>> On 8/1/14, 1:09 PM, lionel.morand@orange.com wrote: >>>>> Hi Steve, >>>>>=20 >>>>> So the topology hiding is not a relevant example here. Even with an i= dentity inserted in the OLR, the client will never know to which server the= request is sent because the only relevant info for the client is the Origi= n-host received in the answer i.e. the id of the agent. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Lionel >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 :=20 >>>>> vendredi 1 ao=FBt 2014 19:49 =C0 : MORAND Lionel IMT/OLN Cc :=20 >>>>> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports=20 >>>>> (was Re: DOIC issue #58 Proposal) >>>>>=20 >>>>> Lionel, >>>>>=20 >>>>> The issue is that there could be multiple/many servers behind the=20 >>>>> agent that is changing the Origin-Host. If one of them is=20 >>>>> overloaded and generates a host report, clients will apply=20 >>>>> overload abatement to all requests sent through that agent. The=20 >>>>> end result would be that the non overloaded servers are under utilize= d. >>>>>=20 >>>>> Steve >>>>>=20 >>>>> On 8/1/14, 11:16 AM, lionel.morand@orange.com wrote: >>>>>> Hi Steve, >>>>>>=20 >>>>>> Not sure to understand. If an agent inserts its identity as Origin-h= ost in answers forwarded from servers, the client will see the agent as the= server. >>>>>> What will be the added-value to add the identity of the server inser= ting the OLR if the client will store this information along the agent id? >>>>>> Sorry if I've missed something... >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Lionel >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve=20 >>>>>> Donovan Envoy=E9 : vendredi 1 ao=FBt 2014 18:10 Cc : dime@ietf.org=20 >>>>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>>>>> issue >>>>>> #58 Proposal) >>>>>>=20 >>>>>> Somewhat on on the path toward generalization, we have a second=20 >>>>>> issue currently open that can be solved by having the DOIC node=20 >>>>>> that inserts an overload report in an answer message include it's=20 >>>>>> own diameter identity in the overload report. >>>>>>=20 >>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin= -Host. >>>>>>=20 >>>>>> This issue points out that existing non DOIC agents are able to=20 >>>>>> change the origin-host in answer messages. One example of where=20 >>>>>> this is done is in topology hiding implementations. >>>>>>=20 >>>>>> This issue can be addressed through attribution of overload reports. >>>>>>=20 >>>>>> As such, I propose that we add a required AVP to the OC-OLR group=20 >>>>>> AVP that carries the diameter identity of the DOIC node that=20 >>>>>> inserted the overload report into the answer message. Issue #66=20 >>>>>> points out the need in host reports and issue #58 points out the nee= d in realm reports. >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>>=20 >>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>> +1 (modulo my comment to generalize) >>>>>>>=20 >>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrot= e: >>>>>>>=20 >>>>>>>> I believe Nirav's view requires all hosts in a realm to be the sam= e vendor and use a proprietary communication protocol to synchronize the ho= st report. Or, if a multiple (redundant or active-active) load-balancing ag= ents are generating the report, they must similarly be synchronized. >>>>>>>>=20 >>>>>>>> Is seems like including the host name per Ulrich's suggestion is a= simple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >>>>>>>> In some applications, the hosts can be completely decoupled (agnos= tic about each other). I think it would be poor to add a synchronization re= quirement just to support DOIC. >>>>>>>>=20 >>>>>>>> -Dave >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>> lionel.morand@orange.com >>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal >>>>>>>>=20 >>>>>>>> Hi Steve, >>>>>>>>=20 >>>>>>>> I agree with Nirav's view. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Lionel >>>>>>>>=20 >>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>>=20 >>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>>>>>=20 >>>>>>>> Steve, >>>>>>>>=20 >>>>>>>> For this issue, I don't agree to include identity of the DOIC node= that sends the report, into the realm reports. >>>>>>>>=20 >>>>>>>> In my view, the issue mentioned below - of two agents not 100% syn= chronize w.r.t the realm-report - is the related to "how agents synchronize= d between themselves" and since that is not standardized we should not be d= eveloping protocol solution for the case which occurs due to this out-of-st= andards solution. >>>>>>>>=20 >>>>>>>> Besides, I don't see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >>>>>>>>=20 >>>>>>>> Also if the agents are not synchronized and if they are playing th= e role of DOIC reacting node then they will apply abatement algorithm based= on different values (for the same realm). So it does not matter if the cli= ent does the same. >>>>>>>>=20 >>>>>>>> Finally, I don't see any value-add of using the "identity of=20 >>>>>>>> the node that sends the realm-report" to discard the other=20 >>>>>>>> report related to the same realm. In other words, this same=20 >>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when=20 >>>>>>>> the overload-report of an realm is active, the client is going=20 >>>>>>>> to ignore all the reports of the same realm which has lower=20 >>>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>>> ignored by the client if their sequence numbers differ. So the=20 >>>>>>>> outcome without including the "identity if the node that sends=20 >>>>>>>> realm report" is same as >>>>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>>>>>> Regards, >>>>>>>> Nirav. >>>>>>>>=20 >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>>>> Donovan >>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: [Dime] DOIC issue #58 Proposal >>>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> Issue #58 deals with the fact that there can be multiple senders o= f realm overload report for the same realm. >>>>>>>>=20 >>>>>>>> Ulrich proposes one aspect of what is required in the issue descri= ption: >>>>>>>>=20 >>>>>>>> "In deployments where more than one node is configured to take the= role of a reporting node for realm-routed-request reports, reacting nodes = may receive in different answer messages different realm-routed-request typ= e OLRs inserted by the different reporting nodes. Although it is expected t= hat the different reporting nodes report more or less the same content, it = cannot be expected that reports are 100% synchronized. Especially sequence = numbers may differ. To allow reacting nodes correctly detect outdates/repla= ys/freshness of OLRs in this scenario, it is proposed that realm-routed-req= uest type OLRs are extended to contain the Diameter Identity of the reporti= ng node that inserted the realm-routed-request type OLR. (e.g. as already p= roposed in draft-donovan-dime-agent-overload-01). Reporting nodes that inse= rt realm-routed-request type OLRs to answer messages MUST also insert their= Diameter Identity. Reacting nodes MUST take the Diameter Identity received= within the OLR into account in order to detect outdates/replays/freshness.= " >>>>>>>>=20 >>>>>>>> I agree with Ulrich that realm reports must include the identity o= f the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports as t= he identity of the sender of the host report is implicitly defined by the o= rigin-host in the answer message. >>>>>>>>=20 >>>>>>>> I also agree that the Diameter Identity of the reporting node be u= sed to determine if a received report is ignored or used to update existing= state. To this end I propose that we add wording that for the duration of= a realm report, the reacting node only listens for updates to the realm re= port from from the DOIC node that sent the realm report that resulted in th= e realm OCS being stored. >>>>>>>>=20 >>>>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>>>>>>=20 >>>>>>>> Steve >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________________________ >>>>>>>> _ _________________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'exp= editeur et le detruire ainsi que les pieces jointes. Les messages electroni= ques etant susceptibles d'alteration, Orange decline toute responsabilite s= i ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or=20 >>>>>>>> privileged information that may be protected by law; they should n= ot 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 h= ave been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>=20 >>>>>> _________________________________________________________________ >>>>>> _ _______________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>> __________________________________________________________________ >>>>> _ ______________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> 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 an= d 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. >>>>>=20 >>>>>=20 >>>> ___________________________________________________________________ >>>> _ _____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged information that may be protected by law; they should not b= e 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. >>>>=20 >>>>=20 >>>=20 >>> ____________________________________________________________________ >>> _ ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>=20 >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=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 nobody Mon Aug 4 21:54:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D191B28AF for ; Mon, 4 Aug 2014 21:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMoLLuBcAA8v for ; Mon, 4 Aug 2014 21:53:46 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C581B28A8 for ; Mon, 4 Aug 2014 21:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12757; q=dns/txt; s=iport; t=1407214426; x=1408424026; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7eZdmzyvxdbaBDY45y3yWNLjbmkeDKwjleoEjdoOSEU=; b=BDN6Qi4PlUZbWnGZkfKCijOvDKXd/voTdx3YIiKWpPRw1bgPfAy4hCy8 h4ZLGyPgAf9VFq5EDK2ElDv553WSEDjoWbm1TnnpIOb7CTG1ppSi20P+D V1RHeX5rG7/5TCEjSz9yBAW76y0v/dsdtQohfkgUt9PLkT0QwWl39Q802 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAIRi4FOtJA2H/2dsb2JhbABSCYMNUlcEy3kKh0oBgRoWd4QDAQEBAwEBAQFkBwsFBwQCAQgRBAEBAQoLEgcnCxQJCAIEAQ0FCBOIHwgNxBMTBIwKgmAHCgEfMQcGBIMlgRwFilWNCJkLg01sgQ05 X-IronPort-AV: E=Sophos;i="5.01,802,1400025600"; d="scan'208";a="66556246" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 05 Aug 2014 04:53:45 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s754rjSN008771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 04:53:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 23:53:45 -0500 From: "Nirav Salot (nsalot)" To: "Shishufeng (Susan)" , Ben Campbell Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8buoAgAAOQgCAAIGHAIAEYa6AgABEAwD//9LCkA== Date: Tue, 5 Aug 2014 04:53:44 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NTaxo3a0ot863Rtew8BkkH93f3o Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:53:50 -0000 +1 Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Susan) Sent: Tuesday, August 05, 2014 8:06 AM To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Hello Ben, Putting S1 node in the OLR would break the principle of topology hiding. If= this is what the operator could accept, what's the benefit to have the age= nt on the route to do the topology hiding? >From my point of view, there are other ways to solve the problem: - If the hosts behind the agent can be enhanced to support overload control= , the agent should be enhanced to support overload control, or be enhanced = to just discard the OLR AVP. - Or by configuration disable the topology hiding functionality of the agen= t since it does not make sense if the S1 could indicate its node identity t= o the client in the OLR. - Or by configuration, the hosts behind the agent should know that the agen= t does not support overload control, then don't send OLR to the client. Best Regards, Susan -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: Tuesday, August 05, 2014 6:32 AM To: Shishufeng (Susan) Cc: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Let me try to rephrase the problem: Consider the following scenario: S1 / C---P--S2 \ S3 "P" is a diameter proxy that does _not_ support DOIC, and performs topology= hiding. The client and servers do support DOIC.=20 Assume S1 becomes overloaded. It sends an host OLR with a reduction percent= age of 100% in an answer to a request sent by C. The answer has an Origin-H= ost of "S1". P receives the answer, and changes Origin-Host to "P". Since P does not sup= port DOIC, it treats the OLR as an "unknown AVP", and forwards it unchanged= . C receives the report, and and entirely stops sending traffic to P. (As far= as C knows, P is the server.)=20 This is not the desired behavior. RFC7068 Req 17 says the following. The be= havior in this example clearly violates the MUST NOT: > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. >=20 If, on the other hand, the OLR internally identified the overloaded node as= "S1", C would at least know that it can't do anything useful with the OLR,= since it doesn't know about S1 due to the topology hiding at P. In this ca= se, it just ignores the OLR. That still violates the SHOULD, but at least d= oes not violate the MUST NOT. On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > Hello, >=20 > I really don't understand the logic for the host to insert its own identi= ty into the overload report. Wouldn't it be the host to report its own over= load report in an answer message to the client? Why we need the agent to do= anything in this case? >=20 > To say the least, if the host can insert its identity into the message, w= hat's the benefit to have the agent for topology hiding? >=20 > Best Regards, > Susan >=20 > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Saturday, August 02, 2014 3:54 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) >=20 > Yes, it could be either. The critical point is that the overloaded host = is indicated by the diameter id in the overload report, not the origin-host= AVP. >=20 > Steve >=20 > On 8/1/14, 2:02 PM, Ben Campbell wrote: >> I don't think you can conflate "host that generated this OLR" with=20 >> "host that is overloaded". It's perfectly valid for them to not be=20 >> the same thing, even for host reports. (But I'd be happy to include >> both.) >>=20 >> On Aug 1, 2014, at 11:09 AM, Steve Donovan wr= ote: >>=20 >>> Somewhat on on the path toward generalization, we have a second issue c= urrently open that can be solved by having the DOIC node that inserts an ov= erload report in an answer message include it's own diameter identity in th= e overload report. >>>=20 >>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Ho= st. >>>=20 >>> This issue points out that existing non DOIC agents are able to change = the origin-host in answer messages. One example of where this is done is i= n topology hiding implementations. >>>=20 >>> This issue can be addressed through attribution of overload reports. >>>=20 >>> As such, I propose that we add a required AVP to the OC-OLR group AVP t= hat carries the diameter identity of the DOIC node that inserted the overlo= ad report into the answer message. Issue #66 points out the need in host r= eports and issue #58 points out the need in realm reports. >>>=20 >>> Steve >>>=20 >>>=20 >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>>=20 >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>=20 >>>>> I believe Nirav's view requires all hosts in a realm to be the same v= endor and use a proprietary communication protocol to synchronize the host = report. Or, if a multiple (redundant or active-active) load-balancing agent= s are generating the report, they must similarly be synchronized. >>>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>>> In some applications, the hosts can be completely decoupled (agnostic= about each other). I think it would be poor to add a synchronization requi= rement just to support DOIC. >>>>> -Dave >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>> lionel.morand@orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>> with Nirav's view. >>>>> Regards, >>>>> Lionel >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I= =20 >>>>> don't agree to include identity of the DOIC node that sends the repor= t, into the realm reports. >>>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>>> Finally, I don't see any value-add of using the "identity of the=20 >>>>> node that sends the realm-report" to discard the other report=20 >>>>> related to the same realm. In other words, this same logic can be=20 >>>>> achieved using sequence-numbers as well, i.e. when the=20 >>>>> overload-report of an realm is active, the client is going to=20 >>>>> ignore all the reports of the same realm which has lower sequence=20 >>>>> number value. So in essence, when two agents are sending=20 >>>>> realm-reports, one of the reports is automatically ignored by the=20 >>>>> client if their sequence numbers differ. So the outcome without=20 >>>>> including the "identity if the node that sends realm report" is=20 >>>>> same as >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>> Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>=20 >>>>> Issue #58 deals with the fact that there can be multiple senders of r= ealm overload report for the same realm. >>>>>=20 >>>>> Ulrich proposes one aspect of what is required in the issue descripti= on: >>>>>=20 >>>>> "In deployments where more than one node is configured to take the ro= le of a reporting node for realm-routed-request reports, reacting nodes may= receive in different answer messages different realm-routed-request type O= LRs inserted by the different reporting nodes. Although it is expected that= the different reporting nodes report more or less the same content, it can= not be expected that reports are 100% synchronized. Especially sequence num= bers may differ. To allow reacting nodes correctly detect outdates/replays/= freshness of OLRs in this scenario, it is proposed that realm-routed-reques= t type OLRs are extended to contain the Diameter Identity of the reporting = node that inserted the realm-routed-request type OLR. (e.g. as already prop= osed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their Di= ameter Identity. Reacting nodes MUST take the Diameter Identity received wi= thin the OLR into account in order to detect outdates/replays/freshness." >>>>>=20 >>>>> I agree with Ulrich that realm reports must include the identity of t= he DOIC node that sends the report. This would be an optional AVP only req= uired for realm reports. It would not be required for host reports as the = identity of the sender of the host report is implicitly defined by the orig= in-host in the answer message. >>>>>=20 >>>>> I also agree that the Diameter Identity of the reporting node be used= to determine if a received report is ignored or used to update existing st= ate. To this end I propose that we add wording that for the duration of a = realm report, the reacting node only listens for updates to the realm repor= t from from the DOIC node that sent the realm report that resulted in the r= ealm OCS being stored. >>>>>=20 >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>>>=20 >>>>> Steve >>>>>=20 >>>>>=20 >>>>> __________________________________________________________________ >>>>> _______________________________________________________ >>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur = et le detruire ainsi que les pieces jointes. Les messages electroniques eta= nt susceptibles d'alteration, Orange decline toute responsabilite si ce mes= sage a ete altere, deforme ou falsifie. Merci. >>>>> This message and its attachments may contain confidential or=20 >>>>> 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 an= d 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. >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > 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 nobody Tue Aug 5 00:22:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC41B291B for ; Tue, 5 Aug 2014 00:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e85xy11HoCqj for ; Tue, 5 Aug 2014 00:22:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE691A032A for ; Tue, 5 Aug 2014 00:22:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 440E222CA99; Tue, 5 Aug 2014 09:22:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2124F238055; Tue, 5 Aug 2014 09:22:44 +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.03.0181.006; Tue, 5 Aug 2014 09:22:43 +0200 From: To: "Shishufeng (Susan)" , Ben Campbell , "Nirav Salot (nsalot)" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u7+ZEAgAAOQgCAAIGHAIAEYa6AgABEAwCAACafAIAASycZ Date: Tue, 5 Aug 2014 07:22:42 +0000 Message-ID: <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.5.60019 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3ya7MAMVYUjQhRLghVx92xiVBPw Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 07:22:50 -0000 Exactly what I said :-) Topology hiding is a non-issue. It is just a matter of configuration. Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- +1 Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Susan) Sent: Tuesday, August 05, 2014 8:06 AM To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Hello Ben, Putting S1 node in the OLR would break the principle of topology hiding. If= this is what the operator could accept, what's the benefit to have the age= nt on the route to do the topology hiding? >From my point of view, there are other ways to solve the problem: - If the hosts behind the agent can be enhanced to support overload control= , the agent should be enhanced to support overload control, or be enhanced = to just discard the OLR AVP. - Or by configuration disable the topology hiding functionality of the agen= t since it does not make sense if the S1 could indicate its node identity t= o the client in the OLR. - Or by configuration, the hosts behind the agent should know that the agen= t does not support overload control, then don't send OLR to the client. Best Regards, Susan -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: Tuesday, August 05, 2014 6:32 AM To: Shishufeng (Susan) Cc: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Let me try to rephrase the problem: Consider the following scenario: S1 / C---P--S2 \ S3 "P" is a diameter proxy that does _not_ support DOIC, and performs topology= hiding. The client and servers do support DOIC. Assume S1 becomes overloaded. It sends an host OLR with a reduction percent= age of 100% in an answer to a request sent by C. The answer has an Origin-H= ost of "S1". P receives the answer, and changes Origin-Host to "P". Since P does not sup= port DOIC, it treats the OLR as an "unknown AVP", and forwards it unchanged. C receives the report, and and entirely stops sending traffic to P. (As far= as C knows, P is the server.) This is not the desired behavior. RFC7068 Req 17 says the following. The be= havior in this example clearly violates the MUST NOT: > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. > If, on the other hand, the OLR internally identified the overloaded node as= "S1", C would at least know that it can't do anything useful with the OLR,= since it doesn't know about S1 due to the topology hiding at P. In this ca= se, it just ignores the OLR. That still violates the SHOULD, but at least d= oes not violate the MUST NOT. On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > Hello, > > I really don't understand the logic for the host to insert its own identi= ty into the overload report. Wouldn't it be the host to report its own over= load report in an answer message to the client? Why we need the agent to do= anything in this case? > > To say the least, if the host can insert its identity into the message, w= hat's the benefit to have the agent for topology hiding? > > Best Regards, > Susan > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Saturday, August 02, 2014 3:54 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC > issue #58 Proposal) > > Yes, it could be either. The critical point is that the overloaded host = is indicated by the diameter id in the overload report, not the origin-host= AVP. > > Steve > > On 8/1/14, 2:02 PM, Ben Campbell wrote: >> I don't think you can conflate "host that generated this OLR" with >> "host that is overloaded". It's perfectly valid for them to not be >> the same thing, even for host reports. (But I'd be happy to include >> both.) >> >> On Aug 1, 2014, at 11:09 AM, Steve Donovan wr= ote: >> >>> Somewhat on on the path toward generalization, we have a second issue c= urrently open that can be solved by having the DOIC node that inserts an ov= erload report in an answer message include it's own diameter identity in th= e overload report. >>> >>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Ho= st. >>> >>> This issue points out that existing non DOIC agents are able to change = the origin-host in answer messages. One example of where this is done is i= n topology hiding implementations. >>> >>> This issue can be addressed through attribution of overload reports. >>> >>> As such, I propose that we add a required AVP to the OC-OLR group AVP t= hat carries the diameter identity of the DOIC node that inserted the overlo= ad report into the answer message. Issue #66 points out the need in host r= eports and issue #58 points out the need in realm reports. >>> >>> Steve >>> >>> >>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>> +1 (modulo my comment to generalize) >>>> >>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>> >>>>> I believe Nirav's view requires all hosts in a realm to be the same v= endor and use a proprietary communication protocol to synchronize the host = report. Or, if a multiple (redundant or active-active) load-balancing agent= s are generating the report, they must similarly be synchronized. >>>>> Is seems like including the host name per Ulrich's suggestion is a s= imple way of avoiding proprietary mechanisms or coupling between hosts and = agents. >>>>> In some applications, the hosts can be completely decoupled (agnostic= about each other). I think it would be poor to add a synchronization requi= rement just to support DOIC. >>>>> -Dave >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>> lionel.morand@orange.com >>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>> with Nirav's view. >>>>> Regards, >>>>> Lionel >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I >>>>> don't agree to include identity of the DOIC node that sends the repor= t, into the realm reports. >>>>> In my view, the issue mentioned below - of two agents not 100% synch= ronize w.r.t the realm-report - is the related to "how agents synchronized = between themselves" and since that is not standardized we should not be dev= eloping protocol solution for the case which occurs due to this out-of-stan= dards solution. >>>>> Besides, I don't see any issue due to slight miss-synchronization of= the realm-reports between two agents since they should still represent the= realm load more or less accurately. >>>>> Also if the agents are not synchronized and if they are playing the = role of DOIC reacting node then they will apply abatement algorithm based o= n different values (for the same realm). So it does not matter if the clien= t does the same. >>>>> Finally, I don't see any value-add of using the "identity of the >>>>> node that sends the realm-report" to discard the other report >>>>> related to the same realm. In other words, this same logic can be >>>>> achieved using sequence-numbers as well, i.e. when the >>>>> overload-report of an realm is active, the client is going to >>>>> ignore all the reports of the same realm which has lower sequence >>>>> number value. So in essence, when two agents are sending >>>>> realm-reports, one of the reports is automatically ignored by the >>>>> client if their sequence numbers differ. So the outcome without >>>>> including the "identity if the node that sends realm report" is >>>>> same as >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>> Regards, >>>>> Nirav. >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>> Donovan >>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>> >>>>> Issue #58 deals with the fact that there can be multiple senders of r= ealm overload report for the same realm. >>>>> >>>>> Ulrich proposes one aspect of what is required in the issue descripti= on: >>>>> >>>>> "In deployments where more than one node is configured to take the ro= le of a reporting node for realm-routed-request reports, reacting nodes may= receive in different answer messages different realm-routed-request type O= LRs inserted by the different reporting nodes. Although it is expected that= the different reporting nodes report more or less the same content, it can= not be expected that reports are 100% synchronized. Especially sequence num= bers may differ. To allow reacting nodes correctly detect outdates/replays/= freshness of OLRs in this scenario, it is proposed that realm-routed-reques= t type OLRs are extended to contain the Diameter Identity of the reporting = node that inserted the realm-routed-request type OLR. (e.g. as already prop= osed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their Di= ameter Identity. Reacting nodes MUST take the Diameter Identity received wi= thin the OLR into account in order to detect outdates/replays/freshness." >>>>> >>>>> I agree with Ulrich that realm reports must include the identity of t= he DOIC node that sends the report. This would be an optional AVP only req= uired for realm reports. It would not be required for host reports as the = identity of the sender of the host report is implicitly defined by the orig= in-host in the answer message. >>>>> >>>>> I also agree that the Diameter Identity of the reporting node be used= to determine if a received report is ignored or used to update existing st= ate. To this end I propose that we add wording that for the duration of a = realm report, the reacting node only listens for updates to the realm repor= t from from the DOIC node that sent the realm report that resulted in the r= ealm OCS being stored. >>>>> >>>>> The effect should be that the reacting node will accept a realm repor= t from anyone when there is no active OLR for the realm but it will only li= sten to one reporting node when it has an active report. >>>>> >>>>> Steve >>>>> >>>>> >>>>> __________________________________________________________________ >>>>> _______________________________________________________ >>>>> 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 eta= nt susceptibles d'alteration, Orange decline toute responsabilite si ce mes= sage 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 an= d 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. >>>>> _______________________________________________ >>>>> 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 _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Aug 5 05:16:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8C41A0108 for ; Tue, 5 Aug 2014 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qSEWcZe6a5P for ; Tue, 5 Aug 2014 05:16:47 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684B21A00EC for ; Tue, 5 Aug 2014 05:16:47 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58053 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XEdfX-0003Pu-Uk for dime@ietf.org; Tue, 05 Aug 2014 05:16:46 -0700 Message-ID: <53E0CB2B.8080207@usdonovans.com> Date: Tue, 05 Aug 2014 07:16:43 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> In-Reply-To: <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cO2t1SCG8cwOkB2EgAmLft6JKVw Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 12:16:51 -0000 How does operator A tell operator B to turn off topology hiding in=20 operator B's network? Keep in mind as well that topology hiding is just one example of a=20 feature that would require an agent to change the origin-host in answer=20 messages. There may be others. We need to solve the general problem=20 and, if possible, solve it through signalling, not configuration. Steve On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: > Exactly what I said :-) > Topology hiding is a non-issue. It is just a matter of configuration. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Nirav Salot (nsalot) a =E9crit ---- > > > +1 > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Susa= n) > Sent: Tuesday, August 05, 2014 8:06 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > Hello Ben, > > Putting S1 node in the OLR would break the principle of topology hiding= =2E If this is what the operator could accept, what's the benefit to have= the agent on the route to do the topology hiding? > > >From my point of view, there are other ways to solve the problem: > > - If the hosts behind the agent can be enhanced to support overload con= trol, the agent should be enhanced to support overload control, or be enh= anced to just discard the OLR AVP. > - Or by configuration disable the topology hiding functionality of the = agent since it does not make sense if the S1 could indicate its node iden= tity to the client in the OLR. > - Or by configuration, the hosts behind the agent should know that the = agent does not support overload control, then don't send OLR to the clien= t. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 6:32 AM > To: Shishufeng (Susan) > Cc: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > Let me try to rephrase the problem: > > Consider the following scenario: > > S1 > / > C---P--S2 > \ > S3 > > "P" is a diameter proxy that does _not_ support DOIC, and performs topo= logy hiding. The client and servers do support DOIC. > > Assume S1 becomes overloaded. It sends an host OLR with a reduction per= centage of 100% in an answer to a request sent by C. The answer has an Or= igin-Host of "S1". > > P receives the answer, and changes Origin-Host to "P". Since P does not= support DOIC, it treats the OLR as an "unknown AVP", and forwards it unc= hanged. > > C receives the report, and and entirely stops sending traffic to P. (As= far as C knows, P is the server.) > > This is not the desired behavior. RFC7068 Req 17 says the following. Th= e behavior in this example clearly violates the MUST NOT: > >> REQ 17: In a mixed environment with nodes that support the solutio= n >> and nodes that do not, the solution MUST NOT result in >> materially less useful throughput during overload as would= >> have resulted if the solution were not present. It SHOULD= >> result in less severe overload in this environment. >> > If, on the other hand, the OLR internally identified the overloaded nod= e as "S1", C would at least know that it can't do anything useful with th= e OLR, since it doesn't know about S1 due to the topology hiding at P. In= this case, it just ignores the OLR. That still violates the SHOULD, but = at least does not violate the MUST NOT. > > > > On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > >> Hello, >> >> I really don't understand the logic for the host to insert its own ide= ntity into the overload report. Wouldn't it be the host to report its own= overload report in an answer message to the client? Why we need the agen= t to do anything in this case? >> >> To say the least, if the host can insert its identity into the message= , what's the benefit to have the agent for topology hiding? >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Saturday, August 02, 2014 3:54 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Yes, it could be either. The critical point is that the overloaded ho= st is indicated by the diameter id in the overload report, not the origin= -host AVP. >> >> Steve >> >> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>> I don't think you can conflate "host that generated this OLR" with >>> "host that is overloaded". It's perfectly valid for them to not be >>> the same thing, even for host reports. (But I'd be happy to include >>> both.) >>> >>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>> >>>> Somewhat on on the path toward generalization, we have a second issu= e currently open that can be solved by having the DOIC node that inserts = an overload report in an answer message include it's own diameter identit= y in the overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin= -Host. >>>> >>>> This issue points out that existing non DOIC agents are able to chan= ge the origin-host in answer messages. One example of where this is done= is in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports.= >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group AV= P that carries the diameter identity of the DOIC node that inserted the o= verload report into the answer message. Issue #66 points out the need in= host reports and issue #58 points out the need in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrot= e: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the sam= e vendor and use a proprietary communication protocol to synchronize the = host report. Or, if a multiple (redundant or active-active) load-balancin= g agents are generating the report, they must similarly be synchronized. >>>>>> Is seems like including the host name per Ulrich's suggestion is= a simple way of avoiding proprietary mechanisms or coupling between host= s and agents. >>>>>> In some applications, the hosts can be completely decoupled (agnos= tic about each other). I think it would be poor to add a synchronization = requirement just to support DOIC. >>>>>> -Dave >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>> lionel.morand@orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>> with Nirav's view. >>>>>> Regards, >>>>>> Lionel >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue= , I >>>>>> don't agree to include identity of the DOIC node that sends the re= port, into the realm reports. >>>>>> In my view, the issue mentioned below - of two agents not 100% s= ynchronize w.r.t the realm-report - is the related to "how agents synchro= nized between themselves" and since that is not standardized we should no= t be developing protocol solution for the case which occurs due to this o= ut-of-standards solution. >>>>>> Besides, I don't see any issue due to slight miss-synchronizatio= n of the realm-reports between two agents since they should still represe= nt the realm load more or less accurately. >>>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm b= ased on different values (for the same realm). So it does not matter if t= he client does the same. >>>>>> Finally, I don't see any value-add of using the "identity of the= >>>>>> node that sends the realm-report" to discard the other report >>>>>> related to the same realm. In other words, this same logic can be >>>>>> achieved using sequence-numbers as well, i.e. when the >>>>>> overload-report of an realm is active, the client is going to >>>>>> ignore all the reports of the same realm which has lower sequence >>>>>> number value. So in essence, when two agents are sending >>>>>> realm-reports, one of the reports is automatically ignored by the >>>>>> client if their sequence numbers differ. So the outcome without >>>>>> including the "identity if the node that sends realm report" is >>>>>> same as >>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will o= nly listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>> Donovan >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders o= f realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descri= ption: >>>>>> >>>>>> "In deployments where more than one node is configured to take the= role of a reporting node for realm-routed-request reports, reacting node= s may receive in different answer messages different realm-routed-request= type OLRs inserted by the different reporting nodes. Although it is expe= cted that the different reporting nodes report more or less the same cont= ent, it cannot be expected that reports are 100% synchronized. Especially= sequence numbers may differ. To allow reacting nodes correctly detect ou= tdates/replays/freshness of OLRs in this scenario, it is proposed that re= alm-routed-request type OLRs are extended to contain the Diameter Identit= y of the reporting node that inserted the realm-routed-request type OLR. = (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Repor= ting nodes that insert realm-routed-request type OLRs to answer messages = MUST also insert their Diameter Identity. Reacting nodes MUST take the Di= ameter Identity received within the OLR into account in order to detect o= utdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity o= f the DOIC node that sends the report. This would be an optional AVP onl= y required for realm reports. It would not be required for host reports = as the identity of the sender of the host report is implicitly defined by= the origin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be u= sed to determine if a received report is ignored or used to update existi= ng state. To this end I propose that we add wording that for the duratio= n of a realm report, the reacting node only listens for updates to the re= alm report from from the DOIC node that sent the realm report that result= ed in the realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will on= ly listen to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> __________________________________________________________________= >>>>>> _______________________________________________________ >>>>>> 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'expedite= ur et le detruire ainsi que les pieces jointes. Les messages electronique= s 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 n= ot 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 h= ave been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> 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 > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Aug 5 05:45:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001301A01A8 for ; Tue, 5 Aug 2014 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvNwpSyApXNG for ; Tue, 5 Aug 2014 05:45:33 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146631A0194 for ; Tue, 5 Aug 2014 05:45:33 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58135 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XEe7L-00020W-Rk for dime@ietf.org; Tue, 05 Aug 2014 05:45:32 -0700 Message-ID: <53E0D1E7.5080804@usdonovans.com> Date: Tue, 05 Aug 2014 07:45:27 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBE0AB.4040505@usdonovans.com> <1C7A057F-69D7-4A24-BDAC-7947F7058322@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62069@SZXEMA512-MBX.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mvhMHVkvAl9gX2ukOh38YRxRaEE Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 12:45:42 -0000 Susan, Nirav, Don't take Ben's example as being literal. The reports that change over the overload percentage could happen over a period of time, they don't have to be absolutely in sequence. It is also quite likely that the sequence numbers would overlap in this scenario. Remember how we got here. The two generators of realm reports start with everything in sync, including sequence numbers. Then there is a localized loss of communication between the two sources. This could also cause the two sources to have a different view of the overload state of the realm. source 1: seq 1 10% <-- value used source 2: seq 1 10% . . . source 1: seq 100 10% source 2: seq 100 10% LOSS OF COMMUNICATION BETWEEN SOURCES source 1: seq 100 10% source 2: seq 100 10% source 1: seq 100 10% source 2: seq 101 50% <-- value used . . . source 1: seq 100 10% source 2: seq 101 50% source 1: seq 100 20% (value not used because sequence number <= previous seq no) source 2: seq 101 50% source 1: seq 102 25% <-- value used source 2: seq 101 50% . . . source 1: seq 102 25% source 2: seq 102 60% source 1: seq 102 25% source 2: seq 103 50% <-- value used . . . AND SO ON More on Nirav's question about whether this is a bad thing in a separate email. Steve On 8/4/14, 11:38 PM, Nirav Salot (nsalot) wrote: > On top of what Susan mentioned below, Ben's example assumes that the realm-reports are out of sync but the sequence numbers are magically synchronized such that each report (from different nodes) has monotonously increasing sequence number. > > Besides, we are trying to solve non-issue here - that of "how to make the client ignore one of the realm-report when the two reports have big difference between them". > Shouldn't the system administrator (and the operator) need to worry about fixing the main issue here? > > Finally, I don't see any issue if a client sees two reports with big jump in their values. > This may be very normal case (or as corner case as we are discussing here of two report generating nodes out-of-sync with each other), e.g. when the client receives 10% report (host/realm) and then there is no communication between the client and the report generator while the report changes from 10% to 50%. > So the client needs to anyway handle this. > > Regards, > Nirav. > > -----Original Message----- > From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] > Sent: Tuesday, August 05, 2014 7:45 AM > To: Ben Campbell; Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: [Dime] DOIC issue #58 Proposal > > Hello Ben, > > I don't understand how the overload report of the same realm in a short period can have such big jump between each other. My understanding is that the overload of the realm should be almost the same to all the agents having the full view of the realm, though there might be little difference which has minor impact on overload control. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 6:01 AM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC issue #58 Proposal > > > On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) wrote: > >> In this scenario, >>> Now, assume that the realm report generators lose the ability to communicate due to some localized failure. The realm is known to be overloaded so realm reports need to be sent. Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed. >> >> Can you explain how did you come to this conclusion? >>> One effect can be a thrashing between 10% reduction and 50% reduction. >> >> The client will ignore the report with lower sequence number and so I don't see the thrashing between 10% and 50%. > I think the example is a bit over simplified, in that you seem to assume one 10% report and one 50% report. What you probably really have is a series of reports from each source. I'm not talking about re-transmissions of the same report, but reports with changes. > > For example, assume all of these are realm reports: > > source 1: seq 1 10% > source 2: seq 2 50% > source 1: seq 3: 11% > source 2: seq 4: 55% > source 1: seq 5: 0% > source 2: seq 6: 45% > > This gives the sort of flapping that Steve referred to. Currently the "source" part is not reported, so from the reacting node's perspective, this is indistinguishable from the following: > > source 1: seq 1 10% > source 1: seq 2 50% > source 1: seq 3: 11% > source 1: seq 4: 55% > source 1: seq 5: 0% > source 1: seq 6: 45% > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Aug 5 05:48:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DED1A0AF1 for ; Tue, 5 Aug 2014 05:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er8GLKa1u_MJ for ; Tue, 5 Aug 2014 05:48:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADDA1A0AEE for ; Tue, 5 Aug 2014 05:48:54 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58136 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XEeAd-0004j9-Rr for dime@ietf.org; Tue, 05 Aug 2014 05:48:53 -0700 Message-ID: <53E0D2B3.7070905@usdonovans.com> Date: Tue, 05 Aug 2014 07:48:51 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <8411_1406908703_53DBB91F_8411_9769_1_6B7134B31289DC4FAF731D844122B36E687DBE@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53DBE0AB.4040505@usdonovans.com> <1C7A057F-69D7-4A24-BDAC-7947F7058322@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62069@SZXEMA512-MBX.china.huawei.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080101010906060501010201" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1cpMmWSEjwf1Co46aKBLIwk4xiY Subject: [Dime] Non-converging oscillations (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 12:48:58 -0000 This is a multi-part message in MIME format. --------------080101010906060501010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, We have the following requirement in RFC 7068: REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. The requirement says the solution MUST not introduce non-converging oscillations. I believe we at least have an oscillation in this scenario. How do we determine if this can result in a non-converging oscillation? Steve On 8/4/14, 11:38 PM, Nirav Salot (nsalot) wrote: > On top of what Susan mentioned below, Ben's example assumes that the realm-reports are out of sync but the sequence numbers are magically synchronized such that each report (from different nodes) has monotonously increasing sequence number. > > Besides, we are trying to solve non-issue here - that of "how to make the client ignore one of the realm-report when the two reports have big difference between them". > Shouldn't the system administrator (and the operator) need to worry about fixing the main issue here? > > Finally, I don't see any issue if a client sees two reports with big jump in their values. > This may be very normal case (or as corner case as we are discussing here of two report generating nodes out-of-sync with each other), e.g. when the client receives 10% report (host/realm) and then there is no communication between the client and the report generator while the report changes from 10% to 50%. > So the client needs to anyway handle this. > > Regards, > Nirav. > > -----Original Message----- > From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] > Sent: Tuesday, August 05, 2014 7:45 AM > To: Ben Campbell; Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: [Dime] DOIC issue #58 Proposal > > Hello Ben, > > I don't understand how the overload report of the same realm in a short period can have such big jump between each other. My understanding is that the overload of the realm should be almost the same to all the agents having the full view of the realm, though there might be little difference which has minor impact on overload control. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 6:01 AM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC issue #58 Proposal > > > On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) wrote: > >> In this scenario, >>> Now, assume that the realm report generators lose the ability to communicate due to some localized failure. The realm is known to be overloaded so realm reports need to be sent. Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed. >> >> Can you explain how did you come to this conclusion? >>> One effect can be a thrashing between 10% reduction and 50% reduction. >> >> The client will ignore the report with lower sequence number and so I don't see the thrashing between 10% and 50%. > I think the example is a bit over simplified, in that you seem to assume one 10% report and one 50% report. What you probably really have is a series of reports from each source. I'm not talking about re-transmissions of the same report, but reports with changes. > > For example, assume all of these are realm reports: > > source 1: seq 1 10% > source 2: seq 2 50% > source 1: seq 3: 11% > source 2: seq 4: 55% > source 1: seq 5: 0% > source 2: seq 6: 45% > > This gives the sort of flapping that Steve referred to. Currently the "source" part is not reported, so from the reacting node's perspective, this is indistinguishable from the following: > > source 1: seq 1 10% > source 1: seq 2 50% > source 1: seq 3: 11% > source 1: seq 4: 55% > source 1: seq 5: 0% > source 1: seq 6: 45% > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------080101010906060501010201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

We have the following requirement in RFC 7068:

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.
The requirement says the solution MUST not introduce non-converging oscillations.

I believe we at least have an oscillation in this scenario.  How do we determine if this can result in a non-converging oscillation?

Steve


On 8/4/14, 11:38 PM, Nirav Salot (nsalot) wrote:
On top of what Susan mentioned below, Ben's example assumes that the realm-reports are out of sync but the sequence numbers are magically synchronized such that each report (from different nodes) has monotonously increasing sequence number.

Besides, we are trying to solve non-issue here - that of "how to make the client ignore one of the realm-report when the two reports have big difference between them".
Shouldn't the system administrator (and the operator) need to worry about fixing the main issue here?

Finally, I don't see any issue if a client sees two reports with big jump in their values.
This may be very normal case (or as corner case as we are discussing here of two report generating nodes out-of-sync with each other), e.g. when the client receives 10% report (host/realm) and then there is no communication between the client and the report generator while the report changes from 10% to 50%.
So the client needs to anyway handle this. 

Regards,
Nirav.

-----Original Message-----
From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] 
Sent: Tuesday, August 05, 2014 7:45 AM
To: Ben Campbell; Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: [Dime] DOIC issue #58 Proposal

Hello Ben,

I don't understand how the overload report of the same realm in a short period can have such big jump between each other. My understanding is that the overload of the realm should be almost the same to all the agents having the full view of the realm, though there might be little difference which has minor impact on overload control.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, August 05, 2014 6:01 AM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC issue #58 Proposal


On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) <nsalot@cisco.com> wrote:


In this scenario,

Now, assume that the realm report generators lose the ability to communicate due to some localized failure.  The realm is known to be overloaded so realm reports need to be sent.  Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed.

 
Can you explain how did you come to this conclusion?

One effect can be a thrashing between 10% reduction and 50% reduction.

 
The client will ignore the report with lower sequence number and so I don't see the thrashing between 10% and 50%.

I think the example is a bit over simplified, in that you seem to assume one 10% report and one 50% report. What you probably really have is a series of reports from each source. I'm not talking about re-transmissions of the same report, but reports with changes.

For example, assume all of these are realm reports:

source 1: seq 1 10%
source 2: seq 2 50%
source 1: seq 3: 11%
source 2: seq 4: 55%
source 1: seq 5: 0%
source 2: seq 6: 45%

This gives the sort of flapping that Steve referred to. Currently the "source" part is not reported, so from the reacting node's perspective, this is indistinguishable from the following:

source 1: seq 1 10%
source 1: seq 2 50%
source 1: seq 3: 11%
source 1: seq 4: 55%
source 1: seq 5: 0%
source 1: seq 6: 45%



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

--------------080101010906060501010201-- From nobody Tue Aug 5 05:57:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC051A0AFF for ; Tue, 5 Aug 2014 05:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSvcOc_Mjyqk for ; Tue, 5 Aug 2014 05:57:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A44C1ABB90 for ; Tue, 5 Aug 2014 05:57:35 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D9B2D1B82B1; Tue, 5 Aug 2014 14:57:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C0C2F384049; Tue, 5 Aug 2014 14:57:32 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 5 Aug 2014 14:57:32 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u7+ZEAgAAOQgCAAIGHAIAEYa6AgABEAwCAACafAIAASycZgAAwnoCAACnyAA== Date: Tue, 5 Aug 2014 12:57:31 +0000 Message-ID: <3789_1407243452_53E0D4BC_3789_4351_1_6B7134B31289DC4FAF731D844122B36E692D58@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> In-Reply-To: <53E0CB2B.8080207@usdonovans.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.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.5.111219 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yDXfPn8vqQaJcai4-qQbq1wwd8A Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 12:57:45 -0000 H Steve, I know that topology hiding was onlky one example. But this one was chosen = to show that it was needed to add the id in the OLR. And it is clear that i= t is not the case. Now, as for topology hiding, I think that any agent that will have to chang= e the Origin-Host of a message sent by a server will have to ensure that su= ch a modification has no impact on the normal process of the message as if = the message was sent from the server, whatever the procedure. For instance,= if there is any state linked to the origin-host of the server, this agent = will have to ensure that this state is correctly managed afterwards when th= e origin-host is modified. This is true for server selection as well as for= overload control. A lot of things can be done around proxy/agent. But the protocol does not h= ave to support everything. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mardi 5 ao=FBt 2014 14:17 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) How does operator A tell operator B to turn off topology hiding in=20 operator B's network? Keep in mind as well that topology hiding is just one example of a=20 feature that would require an agent to change the origin-host in answer=20 messages. There may be others. We need to solve the general problem=20 and, if possible, solve it through signalling, not configuration. Steve On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: > Exactly what I said :-) > Topology hiding is a non-issue. It is just a matter of configuration. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Nirav Salot (nsalot) a =E9crit ---- > > > +1 > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Susan) > Sent: Tuesday, August 05, 2014 8:06 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #= 58 Proposal) > > Hello Ben, > > Putting S1 node in the OLR would break the principle of topology hiding. = If this is what the operator could accept, what's the benefit to have the a= gent on the route to do the topology hiding? > > >From my point of view, there are other ways to solve the problem: > > - If the hosts behind the agent can be enhanced to support overload contr= ol, the agent should be enhanced to support overload control, or be enhance= d to just discard the OLR AVP. > - Or by configuration disable the topology hiding functionality of the ag= ent since it does not make sense if the S1 could indicate its node identity= to the client in the OLR. > - Or by configuration, the hosts behind the agent should know that the ag= ent does not support overload control, then don't send OLR to the client. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 6:32 AM > To: Shishufeng (Susan) > Cc: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #= 58 Proposal) > > Let me try to rephrase the problem: > > Consider the following scenario: > > S1 > / > C---P--S2 > \ > S3 > > "P" is a diameter proxy that does _not_ support DOIC, and performs topolo= gy hiding. The client and servers do support DOIC. > > Assume S1 becomes overloaded. It sends an host OLR with a reduction perce= ntage of 100% in an answer to a request sent by C. The answer has an Origin= -Host of "S1". > > P receives the answer, and changes Origin-Host to "P". Since P does not s= upport DOIC, it treats the OLR as an "unknown AVP", and forwards it unchang= ed. > > C receives the report, and and entirely stops sending traffic to P. (As f= ar as C knows, P is the server.) > > This is not the desired behavior. RFC7068 Req 17 says the following. The = behavior in this example clearly violates the MUST NOT: > >> REQ 17: In a mixed environment with nodes that support the solution >> and nodes that do not, the solution MUST NOT result in >> materially less useful throughput during overload as would >> have resulted if the solution were not present. It SHOULD >> result in less severe overload in this environment. >> > If, on the other hand, the OLR internally identified the overloaded node = as "S1", C would at least know that it can't do anything useful with the OL= R, since it doesn't know about S1 due to the topology hiding at P. In this = case, it just ignores the OLR. That still violates the SHOULD, but at least= does not violate the MUST NOT. > > > > On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > >> Hello, >> >> I really don't understand the logic for the host to insert its own ident= ity into the overload report. Wouldn't it be the host to report its own ove= rload report in an answer message to the client? Why we need the agent to d= o anything in this case? >> >> To say the least, if the host can insert its identity into the message, = what's the benefit to have the agent for topology hiding? >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Saturday, August 02, 2014 3:54 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Yes, it could be either. The critical point is that the overloaded host= is indicated by the diameter id in the overload report, not the origin-hos= t AVP. >> >> Steve >> >> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>> I don't think you can conflate "host that generated this OLR" with >>> "host that is overloaded". It's perfectly valid for them to not be >>> the same thing, even for host reports. (But I'd be happy to include >>> both.) >>> >>> On Aug 1, 2014, at 11:09 AM, Steve Donovan w= rote: >>> >>>> Somewhat on on the path toward generalization, we have a second issue = currently open that can be solved by having the DOIC node that inserts an o= verload report in an answer message include it's own diameter identity in t= he overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >>>> >>>> This issue points out that existing non DOIC agents are able to change= the origin-host in answer messages. One example of where this is done is = in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports. >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group AVP = that carries the diameter identity of the DOIC node that inserted the overl= oad report into the answer message. Issue #66 points out the need in host = reports and issue #58 points out the need in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the host= report. Or, if a multiple (redundant or active-active) load-balancing agen= ts are generating the report, they must similarly be synchronized. >>>>>> Is seems like including the host name per Ulrich's suggestion is a= simple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >>>>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization requ= irement just to support DOIC. >>>>>> -Dave >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>> lionel.morand@orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>> with Nirav's view. >>>>>> Regards, >>>>>> Lionel >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue, I >>>>>> don't agree to include identity of the DOIC node that sends the repo= rt, into the realm reports. >>>>>> In my view, the issue mentioned below - of two agents not 100% syn= chronize w.r.t the realm-report - is the related to "how agents synchronize= d between themselves" and since that is not standardized we should not be d= eveloping protocol solution for the case which occurs due to this out-of-st= andards solution. >>>>>> Besides, I don't see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >>>>>> Also if the agents are not synchronized and if they are playing th= e role of DOIC reacting node then they will apply abatement algorithm based= on different values (for the same realm). So it does not matter if the cli= ent does the same. >>>>>> Finally, I don't see any value-add of using the "identity of the >>>>>> node that sends the realm-report" to discard the other report >>>>>> related to the same realm. In other words, this same logic can be >>>>>> achieved using sequence-numbers as well, i.e. when the >>>>>> overload-report of an realm is active, the client is going to >>>>>> ignore all the reports of the same realm which has lower sequence >>>>>> number value. So in essence, when two agents are sending >>>>>> realm-reports, one of the reports is automatically ignored by the >>>>>> client if their sequence numbers differ. So the outcome without >>>>>> including the "identity if the node that sends realm report" is >>>>>> same as >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>> Donovan >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>>>> >>>>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes ma= y receive in different answer messages different realm-routed-request type = OLRs inserted by the different reporting nodes. Although it is expected tha= t the different reporting nodes report more or less the same content, it ca= nnot be expected that reports are 100% synchronized. Especially sequence nu= mbers may differ. To allow reacting nodes correctly detect outdates/replays= /freshness of OLRs in this scenario, it is proposed that realm-routed-reque= st type OLRs are extended to contain the Diameter Identity of the reporting= node that inserted the realm-routed-request type OLR. (e.g. as already pro= posed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert= realm-routed-request type OLRs to answer messages MUST also insert their D= iameter Identity. Reacting nodes MUST take the Diameter Identity received w= ithin the OLR into account in order to detect outdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only re= quired for realm reports. It would not be required for host reports as the= identity of the sender of the host report is implicitly defined by the ori= gin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing s= tate. To this end I propose that we add wording that for the duration of a= realm report, the reacting node only listens for updates to the realm repo= rt from from the DOIC node that sent the realm report that resulted in the = realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> __________________________________________________________________ >>>>>> _______________________________________________________ >>>>>> 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 et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> 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 > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Aug 5 07:18:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC01B2811 for ; Tue, 5 Aug 2014 07:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tvg1353liBJ0 for ; Tue, 5 Aug 2014 07:18:26 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800181A0312 for ; Tue, 5 Aug 2014 07:18:26 -0700 (PDT) Received: from 99-72-204-33.lightspeed.rcsntx.sbcglobal.net ([99.72.204.33]:58333 helo=steves-air-2.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XEfZB-0002qX-Lj; Tue, 05 Aug 2014 07:18:23 -0700 Message-ID: <53E0E7A8.2070501@usdonovans.com> Date: Tue, 05 Aug 2014 09:18:16 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <3789_1407243452_53E0D4BC_3789_4351_1_6B7134B31289DC4FAF731D844122B36E692D58@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <3789_1407243452_53E0D4BC_3789_4351_1_6B7134B31289DC4FAF731D844122B36E692D58@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gqBxIGiYyVAfugCKs9JEpzmhJSs Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 14:18:30 -0000 inline On 8/5/14, 7:57 AM, lionel.morand@orange.com wrote: > H Steve, > > I know that topology hiding was onlky one example. But this one was cho= sen to show that it was needed to add the id in the OLR. And it is clear = that it is not the case. You're further along than me. I'm not yet convinced. There is the=20 potential for this to result in one host report causing a reduction of=20 traffic across a large number of non overloaded servers. This warrants=20 some consideration. The proposal is as follows: - Add the diameter-id of the host into the overload report and use it=20 to indicate the Diameter node that is overloaded. - Add behavior in the reacting node to compare the value in the OLR and=20 the origin-host. If they are different then the reacting node has two=20 options, ignore the report or honor the report. The behavior taken=20 could and probably should be based on local policy. In either case, the=20 reacting node should probably log the fact that the mismatch occurred. =20 How this is done would be implementation specific. - We might want to add wording in DOIC that says that an agent that=20 changes the identity in the OLR is responsible for ensuring that=20 abatement happens on requests targeted to the overloaded host(s). This is a pretty small change that improves the overall resiliency of=20 the DOIC solution and gives operators more control over how they handle=20 overload. > > Now, as for topology hiding, I think that any agent that will have to c= hange the Origin-Host of a message sent by a server will have to ensure t= hat such a modification has no impact on the normal process of the messag= e as if the message was sent from the server, whatever the procedure. For= instance, if there is any state linked to the origin-host of the server,= this agent will have to ensure that this state is correctly managed afte= rwards when the origin-host is modified. This is true for server selectio= n as well as for overload control. I don't disagree with what you are saying about proper implementation of = topology hiding. However, there is no normative definition of topology=20 hiding behavior that we can depend upon being followed. There is also no = way for an existing topology hiding agent to know how to handle overload = control. So any breakage that might happen from existing topology=20 hiding agents cannot be assumed away by saying that the agent needs to=20 properly handle overload control. > > A lot of things can be done around proxy/agent. But the protocol does n= ot have to support everything. No, not everything, just the scenarios where the presence of non DOIC=20 agents breaks the DOIC solution. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mardi 5 ao=FBt 2014 14:17 > =C0 : dime@ietf.org > Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) > > How does operator A tell operator B to turn off topology hiding in > operator B's network? > > Keep in mind as well that topology hiding is just one example of a > feature that would require an agent to change the origin-host in answer= > messages. There may be others. We need to solve the general problem > and, if possible, solve it through signalling, not configuration. > > Steve > > On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >> Exactly what I said :-) >> Topology hiding is a non-issue. It is just a matter of configuration. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Nirav Salot (nsalot) a =E9crit ---- >> >> >> +1 >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Sus= an) >> Sent: Tuesday, August 05, 2014 8:06 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issu= e #58 Proposal) >> >> Hello Ben, >> >> Putting S1 node in the OLR would break the principle of topology hidin= g. If this is what the operator could accept, what's the benefit to have = the agent on the route to do the topology hiding? >> >> >From my point of view, there are other ways to solve the problem: >> >> - If the hosts behind the agent can be enhanced to support overload co= ntrol, the agent should be enhanced to support overload control, or be en= hanced to just discard the OLR AVP. >> - Or by configuration disable the topology hiding functionality of the= agent since it does not make sense if the S1 could indicate its node ide= ntity to the client in the OLR. >> - Or by configuration, the hosts behind the agent should know that the= agent does not support overload control, then don't send OLR to the clie= nt. >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, August 05, 2014 6:32 AM >> To: Shishufeng (Susan) >> Cc: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issu= e #58 Proposal) >> >> Let me try to rephrase the problem: >> >> Consider the following scenario: >> >> S1 >> / >> C---P--S2 >> \ >> S3 >> >> "P" is a diameter proxy that does _not_ support DOIC, and performs top= ology hiding. The client and servers do support DOIC. >> >> Assume S1 becomes overloaded. It sends an host OLR with a reduction pe= rcentage of 100% in an answer to a request sent by C. The answer has an O= rigin-Host of "S1". >> >> P receives the answer, and changes Origin-Host to "P". Since P does no= t support DOIC, it treats the OLR as an "unknown AVP", and forwards it un= changed. >> >> C receives the report, and and entirely stops sending traffic to P. (A= s far as C knows, P is the server.) >> >> This is not the desired behavior. RFC7068 Req 17 says the following. T= he behavior in this example clearly violates the MUST NOT: >> >>> REQ 17: In a mixed environment with nodes that support the solut= ion >>> and nodes that do not, the solution MUST NOT result in >>> materially less useful throughput during overload as wou= ld >>> have resulted if the solution were not present. It SHOU= LD >>> result in less severe overload in this environment. >>> >> If, on the other hand, the OLR internally identified the overloaded no= de as "S1", C would at least know that it can't do anything useful with t= he OLR, since it doesn't know about S1 due to the topology hiding at P. I= n this case, it just ignores the OLR. That still violates the SHOULD, but= at least does not violate the MUST NOT. >> >> >> >> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >> >>> Hello, >>> >>> I really don't understand the logic for the host to insert its own id= entity into the overload report. Wouldn't it be the host to report its ow= n overload report in an answer message to the client? Why we need the age= nt to do anything in this case? >>> >>> To say the least, if the host can insert its identity into the messag= e, what's the benefit to have the agent for topology hiding? >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Saturday, August 02, 2014 3:54 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Yes, it could be either. The critical point is that the overloaded h= ost is indicated by the diameter id in the overload report, not the origi= n-host AVP. >>> >>> Steve >>> >>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>> I don't think you can conflate "host that generated this OLR" with >>>> "host that is overloaded". It's perfectly valid for them to not be >>>> the same thing, even for host reports. (But I'd be happy to include= >>>> both.) >>>> >>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>> >>>>> Somewhat on on the path toward generalization, we have a second iss= ue currently open that can be solved by having the DOIC node that inserts= an overload report in an answer message include it's own diameter identi= ty in the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origi= n-Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to cha= nge the origin-host in answer messages. One example of where this is don= e is in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports= =2E >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group A= VP that carries the diameter identity of the DOIC node that inserted the = overload report into the answer message. Issue #66 points out the need i= n host reports and issue #58 points out the need in realm reports. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wro= te: >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the sa= me vendor and use a proprietary communication protocol to synchronize the= host report. Or, if a multiple (redundant or active-active) load-balanci= ng agents are generating the report, they must similarly be synchronized.= >>>>>>> Is seems like including the host name per Ulrich's suggestion = is a simple way of avoiding proprietary mechanisms or coupling between ho= sts and agents. >>>>>>> In some applications, the hosts can be completely decoupled (agno= stic about each other). I think it would be poor to add a synchronization= requirement just to support DOIC. >>>>>>> -Dave >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>> lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>>> with Nirav's view. >>>>>>> Regards, >>>>>>> Lionel >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this iss= ue, I >>>>>>> don't agree to include identity of the DOIC node that sends the r= eport, into the realm reports. >>>>>>> In my view, the issue mentioned below - of two agents not 100%= synchronize w.r.t the realm-report - is the related to "how agents synch= ronized between themselves" and since that is not standardized we should = not be developing protocol solution for the case which occurs due to this= out-of-standards solution. >>>>>>> Besides, I don't see any issue due to slight miss-synchronizat= ion of the realm-reports between two agents since they should still repre= sent the realm load more or less accurately. >>>>>>> Also if the agents are not synchronized and if they are playin= g the role of DOIC reacting node then they will apply abatement algorithm= based on different values (for the same realm). So it does not matter if= the client does the same. >>>>>>> Finally, I don't see any value-add of using the "identity of t= he >>>>>>> node that sends the realm-report" to discard the other report >>>>>>> related to the same realm. In other words, this same logic can be= >>>>>>> achieved using sequence-numbers as well, i.e. when the >>>>>>> overload-report of an realm is active, the client is going to >>>>>>> ignore all the reports of the same realm which has lower sequence= >>>>>>> number value. So in essence, when two agents are sending >>>>>>> realm-reports, one of the reports is automatically ignored by the= >>>>>>> client if their sequence numbers differ. So the outcome without >>>>>>> including the "identity if the node that sends realm report" is >>>>>>> same as >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>>> Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descr= iption: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take th= e role of a reporting node for realm-routed-request reports, reacting nod= es may receive in different answer messages different realm-routed-reques= t type OLRs inserted by the different reporting nodes. Although it is exp= ected that the different reporting nodes report more or less the same con= tent, it cannot be expected that reports are 100% synchronized. Especiall= y sequence numbers may differ. To allow reacting nodes correctly detect o= utdates/replays/freshness of OLRs in this scenario, it is proposed that r= ealm-routed-request type OLRs are extended to contain the Diameter Identi= ty of the reporting node that inserted the realm-routed-request type OLR.= (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Repo= rting nodes that insert realm-routed-request type OLRs to answer messages= MUST also insert their Diameter Identity. Reacting nodes MUST take the D= iameter Identity received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP on= ly required for realm reports. It would not be required for host reports= as the identity of the sender of the host report is implicitly defined b= y the origin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update exist= ing state. To this end I propose that we add wording that for the durati= on of a realm report, the reacting node only listens for updates to the r= ealm report from from the DOIC node that sent the realm report that resul= ted in the realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will o= nly listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> _________________________________________________________________= _ >>>>>>> _______________________________________________________ >>>>>>> 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'expedit= eur et le detruire ainsi que les pieces jointes. Les messages electroniqu= es etant susceptibles d'alteration, Orange decline toute responsabilite s= i 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 sende= r 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. >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> 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 >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d 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. >> >> _______________________________________________ >> 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 > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Tue Aug 5 10:51:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAB51A046A for ; Tue, 5 Aug 2014 10:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2tXVs6GeoPV for ; Tue, 5 Aug 2014 10:51:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDD61A0076 for ; Tue, 5 Aug 2014 10:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15904; q=dns/txt; s=iport; t=1407261091; x=1408470691; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6c47tPDc3eURkBrgAq/uztanh5iRn3bnLuPHSXTOvzQ=; b=fysl9bm3Cu8n+xxTr6JIhnlCO6VrJQQGYyugF13Bx6UbGOyE5lG4uOAj Az8XPr1TE8dmolr0EeAqPQ7z0gohfz3pLsz4oUTwGB4rIYs2MG0S3MyDU dWQ2e32XcnTKfogpQy0wlB6qM4AdpgPw2+AVcsAOYVM+SIg/AkO2Io5WS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAOAY4VOtJA2E/2dsb2JhbABSCYMNUlcEy2cKh0gBgRYWd4QDAQEBBAEBAWQHFwQCAQgOAwQBAQEKCxIHJwsUCQgCBAESCBOIJw3DYBMEjAqCYAcKAQ4ROAYEgyWBHAWKWY0ImQ2DTWyBBgcXIg X-IronPort-AV: E=Sophos;i="5.01,806,1400025600"; d="scan'208";a="345292142" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2014 17:51:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s75HpTEJ007121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 17:51:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 12:51:29 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8buoAgAAOQgCAAIGHAIAEYa6AgABEAwD//9LCkIAAfXwAgABSJoCAAAh+QA== Date: Tue, 5 Aug 2014 17:51:29 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> In-Reply-To: <53E0CB2B.8080207@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sV50VkwFXXyKHuiqEnUuH-Cwc3M Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 17:51:36 -0000 Steve, What is so difficult here and not sure why two operators are involved since= the proposal is restricted to change of behavior in either the host or the= agent at operator B? Operator B has two choices: - Turn off topology hiding in its agent since agents are not supporting DOI= C yet. - Turn off generation of overload report at the host since topology hiding = is important. These are configuration related issue and interim/transient problems - unti= l the agents are upgraded to support DOIC. So I don't think we need protocol solution for these types of problems. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Tuesday, August 05, 2014 5:47 PM To: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) How does operator A tell operator B to turn off topology hiding in operator= B's network? Keep in mind as well that topology hiding is just one example of a feature = that would require an agent to change the origin-host in answer messages. = There may be others. We need to solve the general problem and, if possible= , solve it through signalling, not configuration. Steve On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: > Exactly what I said :-) > Topology hiding is a non-issue. It is just a matter of configuration. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Nirav Salot (nsalot) a =E9crit ---- > > > +1 > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng=20 > (Susan) > Sent: Tuesday, August 05, 2014 8:06 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > Hello Ben, > > Putting S1 node in the OLR would break the principle of topology hiding. = If this is what the operator could accept, what's the benefit to have the a= gent on the route to do the topology hiding? > > >From my point of view, there are other ways to solve the problem: > > - If the hosts behind the agent can be enhanced to support overload contr= ol, the agent should be enhanced to support overload control, or be enhance= d to just discard the OLR AVP. > - Or by configuration disable the topology hiding functionality of the ag= ent since it does not make sense if the S1 could indicate its node identity= to the client in the OLR. > - Or by configuration, the hosts behind the agent should know that the ag= ent does not support overload control, then don't send OLR to the client. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 6:32 AM > To: Shishufeng (Susan) > Cc: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > Let me try to rephrase the problem: > > Consider the following scenario: > > S1 > / > C---P--S2 > \ > S3 > > "P" is a diameter proxy that does _not_ support DOIC, and performs topolo= gy hiding. The client and servers do support DOIC. > > Assume S1 becomes overloaded. It sends an host OLR with a reduction perce= ntage of 100% in an answer to a request sent by C. The answer has an Origin= -Host of "S1". > > P receives the answer, and changes Origin-Host to "P". Since P does not s= upport DOIC, it treats the OLR as an "unknown AVP", and forwards it unchang= ed. > > C receives the report, and and entirely stops sending traffic to P.=20 > (As far as C knows, P is the server.) > > This is not the desired behavior. RFC7068 Req 17 says the following. The = behavior in this example clearly violates the MUST NOT: > >> REQ 17: In a mixed environment with nodes that support the solution >> and nodes that do not, the solution MUST NOT result in >> materially less useful throughput during overload as would >> have resulted if the solution were not present. It SHOULD >> result in less severe overload in this environment. >> > If, on the other hand, the OLR internally identified the overloaded node = as "S1", C would at least know that it can't do anything useful with the OL= R, since it doesn't know about S1 due to the topology hiding at P. In this = case, it just ignores the OLR. That still violates the SHOULD, but at least= does not violate the MUST NOT. > > > > On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > >> Hello, >> >> I really don't understand the logic for the host to insert its own ident= ity into the overload report. Wouldn't it be the host to report its own ove= rload report in an answer message to the client? Why we need the agent to d= o anything in this case? >> >> To say the least, if the host can insert its identity into the message, = what's the benefit to have the agent for topology hiding? >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Saturday, August 02, 2014 3:54 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> Yes, it could be either. The critical point is that the overloaded host= is indicated by the diameter id in the overload report, not the origin-hos= t AVP. >> >> Steve >> >> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>> I don't think you can conflate "host that generated this OLR" with=20 >>> "host that is overloaded". It's perfectly valid for them to not be=20 >>> the same thing, even for host reports. (But I'd be happy to include >>> both.) >>> >>> On Aug 1, 2014, at 11:09 AM, Steve Donovan w= rote: >>> >>>> Somewhat on on the path toward generalization, we have a second issue = currently open that can be solved by having the DOIC node that inserts an o= verload report in an answer message include it's own diameter identity in t= he overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >>>> >>>> This issue points out that existing non DOIC agents are able to change= the origin-host in answer messages. One example of where this is done is = in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports. >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group AVP = that carries the diameter identity of the DOIC node that inserted the overl= oad report into the answer message. Issue #66 points out the need in host = reports and issue #58 points out the need in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the host= report. Or, if a multiple (redundant or active-active) load-balancing agen= ts are generating the report, they must similarly be synchronized. >>>>>> Is seems like including the host name per Ulrich's suggestion is a= simple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >>>>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization requ= irement just to support DOIC. >>>>>> -Dave >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>> lionel.morand@orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>>> with Nirav's view. >>>>>> Regards, >>>>>> Lionel >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue,= =20 >>>>>> I don't agree to include identity of the DOIC node that sends the re= port, into the realm reports. >>>>>> In my view, the issue mentioned below - of two agents not 100% syn= chronize w.r.t the realm-report - is the related to "how agents synchronize= d between themselves" and since that is not standardized we should not be d= eveloping protocol solution for the case which occurs due to this out-of-st= andards solution. >>>>>> Besides, I don't see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >>>>>> Also if the agents are not synchronized and if they are playing th= e role of DOIC reacting node then they will apply abatement algorithm based= on different values (for the same realm). So it does not matter if the cli= ent does the same. >>>>>> Finally, I don't see any value-add of using the "identity of=20 >>>>>> the node that sends the realm-report" to discard the other report=20 >>>>>> related to the same realm. In other words, this same logic can be=20 >>>>>> achieved using sequence-numbers as well, i.e. when the=20 >>>>>> overload-report of an realm is active, the client is going to=20 >>>>>> ignore all the reports of the same realm which has lower sequence=20 >>>>>> number value. So in essence, when two agents are sending=20 >>>>>> realm-reports, one of the reports is automatically ignored by the=20 >>>>>> client if their sequence numbers differ. So the outcome without=20 >>>>>> including the "identity if the node that sends realm report" is=20 >>>>>> same as >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>> Donovan >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>>>> >>>>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes ma= y receive in different answer messages different realm-routed-request type = OLRs inserted by the different reporting nodes. Although it is expected tha= t the different reporting nodes report more or less the same content, it ca= nnot be expected that reports are 100% synchronized. Especially sequence nu= mbers may differ. To allow reacting nodes correctly detect outdates/replays= /freshness of OLRs in this scenario, it is proposed that realm-routed-reque= st type OLRs are extended to contain the Diameter Identity of the reporting= node that inserted the realm-routed-request type OLR. (e.g. as already pro= posed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert= realm-routed-request type OLRs to answer messages MUST also insert their D= iameter Identity. Reacting nodes MUST take the Diameter Identity received w= ithin the OLR into account in order to detect outdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only re= quired for realm reports. It would not be required for host reports as the= identity of the sender of the host report is implicitly defined by the ori= gin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing s= tate. To this end I propose that we add wording that for the duration of a= realm report, the reacting node only listens for updates to the realm repo= rt from from the DOIC node that sent the realm report that resulted in the = realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> _________________________________________________________________ >>>>>> _ _______________________________________________________ >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> 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 > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Aug 5 13:08:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C00E1B2B54; Tue, 5 Aug 2014 13:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7vYGQzdx_xn; Tue, 5 Aug 2014 13:08:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0071B2B53; Tue, 5 Aug 2014 13:08:17 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s75K8F1q097678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Aug 2014 15:08:16 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Tue, 5 Aug 2014 15:08:14 -0500 X-Mao-Original-Outgoing-Id: 428962094.750291-b93c63e668dd5ec4a5c7b2d8381ca794 Content-Transfer-Encoding: quoted-printable Message-Id: To: draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wqdePUYRj8qXYiJix14ztFoe69A Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" , "dime@ietf.org list" Subject: [Dime] Gen-ART Telechat Review of draft-ietf-6man-multicast-addr-arch-update-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 20:08:19 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6man-multicast-addr-arch-update-07 Reviewer: Ben Campbell Review Date: 2014-08-05 IETF LC End Date: 2014-07-02 IESG Telechat date: 2014-08-07 Summary: Ready for publication as proposed standard. All of my last-call = comments from version 05 have been addressed. Major issues: None Minor issues: None Nits/editorial comments: None= From nobody Wed Aug 6 06:19:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906E31B2D28 for ; Wed, 6 Aug 2014 06:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV71KaF7XlNt for ; Wed, 6 Aug 2014 06:19:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA37F1B2A0E for ; Wed, 6 Aug 2014 06:19:24 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id B2D891902BA; Wed, 6 Aug 2014 15:19:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 8C849158074; Wed, 6 Aug 2014 15:19:21 +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.03.0181.006; Wed, 6 Aug 2014 15:19:21 +0200 From: To: "Nirav Salot (nsalot)" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u7+ZEAgAAOQgCAAIGHAIAEYa6AgABEAwCAACafAIAASycZgAAwnoCAAF2IgIABZnFQ Date: Wed, 6 Aug 2014 13:19:19 +0000 Message-ID: <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.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: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.5.220019 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/V_oDBljQsv6hXU1S6sxSgk1ePJc Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 13:19:29 -0000 Hi, In order to try to conclude on the fact that an agent modifying the Origin-= host AVP can only be a proxy agent and then such a proxy can be upgraded to= deal with DOIC: >From RFC6733: 6.3. Origin-Host AVP The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and it MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message.=20=20 <<< Relay agents MUST NOT modify this AVP. >>> The value of the Origin-Host AVP is guaranteed to be unique within a single host. Note that the Origin-Host AVP may resolve to more than one address as the Diameter peer may support more than one address. This AVP SHOULD be placed as close to the Diameter header as possible. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) Envoy=E9=A0: mardi 5 ao=FBt 2014 19:51 =C0=A0: Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) Steve, What is so difficult here and not sure why two operators are involved since= the proposal is restricted to change of behavior in either the host or the= agent at operator B? Operator B has two choices: - Turn off topology hiding in its agent since agents are not supporting DOI= C yet. - Turn off generation of overload report at the host since topology hiding = is important. These are configuration related issue and interim/transient problems - unti= l the agents are upgraded to support DOIC. So I don't think we need protocol solution for these types of problems. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Tuesday, August 05, 2014 5:47 PM To: dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) How does operator A tell operator B to turn off topology hiding in operator= B's network? Keep in mind as well that topology hiding is just one example of a feature = that would require an agent to change the origin-host in answer messages. = There may be others. We need to solve the general problem and, if possible= , solve it through signalling, not configuration. Steve On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: > Exactly what I said :-) > Topology hiding is a non-issue. It is just a matter of configuration. > > Lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Nirav Salot (nsalot) a =E9crit ---- > > > +1 > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng > (Susan) > Sent: Tuesday, August 05, 2014 8:06 AM > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > Hello Ben, > > Putting S1 node in the OLR would break the principle of topology hiding. = If this is what the operator could accept, what's the benefit to have the a= gent on the route to do the topology hiding? > > >From my point of view, there are other ways to solve the problem: > > - If the hosts behind the agent can be enhanced to support overload contr= ol, the agent should be enhanced to support overload control, or be enhance= d to just discard the OLR AVP. > - Or by configuration disable the topology hiding functionality of the ag= ent since it does not make sense if the S1 could indicate its node identity= to the client in the OLR. > - Or by configuration, the hosts behind the agent should know that the ag= ent does not support overload control, then don't send OLR to the client. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 6:32 AM > To: Shishufeng (Susan) > Cc: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > Let me try to rephrase the problem: > > Consider the following scenario: > > S1 > / > C---P--S2 > \ > S3 > > "P" is a diameter proxy that does _not_ support DOIC, and performs topolo= gy hiding. The client and servers do support DOIC. > > Assume S1 becomes overloaded. It sends an host OLR with a reduction perce= ntage of 100% in an answer to a request sent by C. The answer has an Origin= -Host of "S1". > > P receives the answer, and changes Origin-Host to "P". Since P does not s= upport DOIC, it treats the OLR as an "unknown AVP", and forwards it unchang= ed. > > C receives the report, and and entirely stops sending traffic to P.=20 > (As far as C knows, P is the server.) > > This is not the desired behavior. RFC7068 Req 17 says the following. The = behavior in this example clearly violates the MUST NOT: > >> REQ 17: In a mixed environment with nodes that support the solution >> and nodes that do not, the solution MUST NOT result in >> materially less useful throughput during overload as would >> have resulted if the solution were not present. It SHOULD >> result in less severe overload in this environment. >> > If, on the other hand, the OLR internally identified the overloaded node = as "S1", C would at least know that it can't do anything useful with the OL= R, since it doesn't know about S1 due to the topology hiding at P. In this = case, it just ignores the OLR. That still violates the SHOULD, but at least= does not violate the MUST NOT. > > > > On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: > >> Hello, >> >> I really don't understand the logic for the host to insert its own ident= ity into the overload report. Wouldn't it be the host to report its own ove= rload report in an answer message to the client? Why we need the agent to d= o anything in this case? >> >> To say the least, if the host can insert its identity into the message, = what's the benefit to have the agent for topology hiding? >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Saturday, August 02, 2014 3:54 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> Yes, it could be either. The critical point is that the overloaded host= is indicated by the diameter id in the overload report, not the origin-hos= t AVP. >> >> Steve >> >> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>> I don't think you can conflate "host that generated this OLR" with=20 >>> "host that is overloaded". It's perfectly valid for them to not be=20 >>> the same thing, even for host reports. (But I'd be happy to include >>> both.) >>> >>> On Aug 1, 2014, at 11:09 AM, Steve Donovan w= rote: >>> >>>> Somewhat on on the path toward generalization, we have a second issue = currently open that can be solved by having the DOIC node that inserts an o= verload report in an answer message include it's own diameter identity in t= he overload report. >>>> >>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-H= ost. >>>> >>>> This issue points out that existing non DOIC agents are able to change= the origin-host in answer messages. One example of where this is done is = in topology hiding implementations. >>>> >>>> This issue can be addressed through attribution of overload reports. >>>> >>>> As such, I propose that we add a required AVP to the OC-OLR group AVP = that carries the diameter identity of the DOIC node that inserted the overl= oad report into the answer message. Issue #66 points out the need in host = reports and issue #58 points out the need in realm reports. >>>> >>>> Steve >>>> >>>> >>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>> +1 (modulo my comment to generalize) >>>>> >>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>> >>>>>> I believe Nirav's view requires all hosts in a realm to be the same = vendor and use a proprietary communication protocol to synchronize the host= report. Or, if a multiple (redundant or active-active) load-balancing agen= ts are generating the report, they must similarly be synchronized. >>>>>> Is seems like including the host name per Ulrich's suggestion is a= simple way of avoiding proprietary mechanisms or coupling between hosts an= d agents. >>>>>> In some applications, the hosts can be completely decoupled (agnosti= c about each other). I think it would be poor to add a synchronization requ= irement just to support DOIC. >>>>>> -Dave >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>> lionel.morand@orange.com >>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>>> with Nirav's view. >>>>>> Regards, >>>>>> Lionel >>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this issue,= =20 >>>>>> I don't agree to include identity of the DOIC node that sends the re= port, into the realm reports. >>>>>> In my view, the issue mentioned below - of two agents not 100% syn= chronize w.r.t the realm-report - is the related to "how agents synchronize= d between themselves" and since that is not standardized we should not be d= eveloping protocol solution for the case which occurs due to this out-of-st= andards solution. >>>>>> Besides, I don't see any issue due to slight miss-synchronization = of the realm-reports between two agents since they should still represent t= he realm load more or less accurately. >>>>>> Also if the agents are not synchronized and if they are playing th= e role of DOIC reacting node then they will apply abatement algorithm based= on different values (for the same realm). So it does not matter if the cli= ent does the same. >>>>>> Finally, I don't see any value-add of using the "identity of=20 >>>>>> the node that sends the realm-report" to discard the other report=20 >>>>>> related to the same realm. In other words, this same logic can be=20 >>>>>> achieved using sequence-numbers as well, i.e. when the=20 >>>>>> overload-report of an realm is active, the client is going to=20 >>>>>> ignore all the reports of the same realm which has lower sequence=20 >>>>>> number value. So in essence, when two agents are sending=20 >>>>>> realm-reports, one of the reports is automatically ignored by the=20 >>>>>> client if their sequence numbers differ. So the outcome without=20 >>>>>> including the "identity if the node that sends realm report" is=20 >>>>>> same as >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>> Regards, >>>>>> Nirav. >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>> Donovan >>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>> >>>>>> Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. >>>>>> >>>>>> Ulrich proposes one aspect of what is required in the issue descript= ion: >>>>>> >>>>>> "In deployments where more than one node is configured to take the r= ole of a reporting node for realm-routed-request reports, reacting nodes ma= y receive in different answer messages different realm-routed-request type = OLRs inserted by the different reporting nodes. Although it is expected tha= t the different reporting nodes report more or less the same content, it ca= nnot be expected that reports are 100% synchronized. Especially sequence nu= mbers may differ. To allow reacting nodes correctly detect outdates/replays= /freshness of OLRs in this scenario, it is proposed that realm-routed-reque= st type OLRs are extended to contain the Diameter Identity of the reporting= node that inserted the realm-routed-request type OLR. (e.g. as already pro= posed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert= realm-routed-request type OLRs to answer messages MUST also insert their D= iameter Identity. Reacting nodes MUST take the Diameter Identity received w= ithin the OLR into account in order to detect outdates/replays/freshness." >>>>>> >>>>>> I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only re= quired for realm reports. It would not be required for host reports as the= identity of the sender of the host report is implicitly defined by the ori= gin-host in the answer message. >>>>>> >>>>>> I also agree that the Diameter Identity of the reporting node be use= d to determine if a received report is ignored or used to update existing s= tate. To this end I propose that we add wording that for the duration of a= realm report, the reacting node only listens for updates to the realm repo= rt from from the DOIC node that sent the realm report that resulted in the = realm OCS being stored. >>>>>> >>>>>> The effect should be that the reacting node will accept a realm repo= rt from anyone when there is no active OLR for the realm but it will only l= isten to one reporting node when it has an active report. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> _________________________________________________________________ >>>>>> _ _______________________________________________________ >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> 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 > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Aug 6 08:16:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54DC1B27D3 for ; Wed, 6 Aug 2014 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYjg5omSQ3TF for ; Wed, 6 Aug 2014 08:16:13 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70551A07A1 for ; Wed, 6 Aug 2014 08:16:13 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50207 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XF2wk-00016z-CH; Wed, 06 Aug 2014 08:16:12 -0700 Message-ID: <53E246BA.6000202@usdonovans.com> Date: Wed, 06 Aug 2014 10:16:10 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/I-e4q9r9Z7lnYAbN9HCGDAT26Os Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 15:16:17 -0000 Nirav, Here's the cross operator scenario: Operator 1 Operator 2 | | +--+ | |S1| | /+--+ | / +-+ +-+ | +-+ / +--+ |C|-------|A|---|----|A|-----|S2| +-+ +-+ | +-+ \ +--+ | \ | \+--+ | |S3| | +--+ Operator 1 is fully DOIC capable. The agent in operator 2's network is not DOIC enabled. The servers in operator 2's network are DOIC enabled. All traffic from operator 1 targeted for operator 2 flows through=20 operator 2's agent. The agent in operator 2's network changes the origin-host header, maybe=20 for topology hiding reasons, maybe for other reasons. C sends a request that is routed to S1. The request includes the=20 OC-Supported-Features AVP. S1 is overloaded and sends a response with an overload report requesting = a reduction in traffic. In the worst case S1 can send an overload=20 report with a request for a 100% reduction in traffic. C will see this as coming from the identity inserted by operator 2's=20 agent and, as a result will throttle 100% of traffic targeted for=20 operator 2's network despite there being two fully operational servers=20 in operator 2's network. While it may be in operator 2's best interest to upgrade their agent to=20 support DOIC, operator 1 has no ability to make that upgrade happen. Steve On 8/5/14, 12:51 PM, Nirav Salot (nsalot) wrote: > Steve, > > What is so difficult here and not sure why two operators are involved s= ince the proposal is restricted to change of behavior in either the host = or the agent at operator B? > Operator B has two choices: > - Turn off topology hiding in its agent since agents are not supporting= DOIC yet. > - Turn off generation of overload report at the host since topology hid= ing is important. > > These are configuration related issue and interim/transient problems - = until the agents are upgraded to support DOIC. > So I don't think we need protocol solution for these types of problems.= > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Tuesday, August 05, 2014 5:47 PM > To: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > How does operator A tell operator B to turn off topology hiding in oper= ator B's network? > > Keep in mind as well that topology hiding is just one example of a feat= ure that would require an agent to change the origin-host in answer messa= ges. There may be others. We need to solve the general problem and, if = possible, solve it through signalling, not configuration. > > Steve > > On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >> Exactly what I said :-) >> Topology hiding is a non-issue. It is just a matter of configuration. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Nirav Salot (nsalot) a =E9crit ---- >> >> >> +1 >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >> (Susan) >> Sent: Tuesday, August 05, 2014 8:06 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Hello Ben, >> >> Putting S1 node in the OLR would break the principle of topology hidin= g. If this is what the operator could accept, what's the benefit to have = the agent on the route to do the topology hiding? >> >> >From my point of view, there are other ways to solve the problem: >> >> - If the hosts behind the agent can be enhanced to support overload co= ntrol, the agent should be enhanced to support overload control, or be en= hanced to just discard the OLR AVP. >> - Or by configuration disable the topology hiding functionality of the= agent since it does not make sense if the S1 could indicate its node ide= ntity to the client in the OLR. >> - Or by configuration, the hosts behind the agent should know that the= agent does not support overload control, then don't send OLR to the clie= nt. >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, August 05, 2014 6:32 AM >> To: Shishufeng (Susan) >> Cc: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Let me try to rephrase the problem: >> >> Consider the following scenario: >> >> S1 >> / >> C---P--S2 >> \ >> S3 >> >> "P" is a diameter proxy that does _not_ support DOIC, and performs top= ology hiding. The client and servers do support DOIC. >> >> Assume S1 becomes overloaded. It sends an host OLR with a reduction pe= rcentage of 100% in an answer to a request sent by C. The answer has an O= rigin-Host of "S1". >> >> P receives the answer, and changes Origin-Host to "P". Since P does no= t support DOIC, it treats the OLR as an "unknown AVP", and forwards it un= changed. >> >> C receives the report, and and entirely stops sending traffic to P. >> (As far as C knows, P is the server.) >> >> This is not the desired behavior. RFC7068 Req 17 says the following. T= he behavior in this example clearly violates the MUST NOT: >> >>> REQ 17: In a mixed environment with nodes that support the solut= ion >>> and nodes that do not, the solution MUST NOT result in >>> materially less useful throughput during overload as wou= ld >>> have resulted if the solution were not present. It SHOU= LD >>> result in less severe overload in this environment. >>> >> If, on the other hand, the OLR internally identified the overloaded no= de as "S1", C would at least know that it can't do anything useful with t= he OLR, since it doesn't know about S1 due to the topology hiding at P. I= n this case, it just ignores the OLR. That still violates the SHOULD, but= at least does not violate the MUST NOT. >> >> >> >> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >> >>> Hello, >>> >>> I really don't understand the logic for the host to insert its own id= entity into the overload report. Wouldn't it be the host to report its ow= n overload report in an answer message to the client? Why we need the age= nt to do anything in this case? >>> >>> To say the least, if the host can insert its identity into the messag= e, what's the benefit to have the agent for topology hiding? >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Saturday, August 02, 2014 3:54 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Yes, it could be either. The critical point is that the overloaded h= ost is indicated by the diameter id in the overload report, not the origi= n-host AVP. >>> >>> Steve >>> >>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>> I don't think you can conflate "host that generated this OLR" with >>>> "host that is overloaded". It's perfectly valid for them to not be >>>> the same thing, even for host reports. (But I'd be happy to include= >>>> both.) >>>> >>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>> >>>>> Somewhat on on the path toward generalization, we have a second iss= ue currently open that can be solved by having the DOIC node that inserts= an overload report in an answer message include it's own diameter identi= ty in the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origi= n-Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to cha= nge the origin-host in answer messages. One example of where this is don= e is in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports= =2E >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group A= VP that carries the diameter identity of the DOIC node that inserted the = overload report into the answer message. Issue #66 points out the need i= n host reports and issue #58 points out the need in realm reports. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wro= te: >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the sa= me vendor and use a proprietary communication protocol to synchronize the= host report. Or, if a multiple (redundant or active-active) load-balanci= ng agents are generating the report, they must similarly be synchronized.= >>>>>>> Is seems like including the host name per Ulrich's suggestion = is a simple way of avoiding proprietary mechanisms or coupling between ho= sts and agents. >>>>>>> In some applications, the hosts can be completely decoupled (agno= stic about each other). I think it would be poor to add a synchronization= requirement just to support DOIC. >>>>>>> -Dave >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>> lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>>> with Nirav's view. >>>>>>> Regards, >>>>>>> Lionel >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this iss= ue, >>>>>>> I don't agree to include identity of the DOIC node that sends the= report, into the realm reports. >>>>>>> In my view, the issue mentioned below - of two agents not 100%= synchronize w.r.t the realm-report - is the related to "how agents synch= ronized between themselves" and since that is not standardized we should = not be developing protocol solution for the case which occurs due to this= out-of-standards solution. >>>>>>> Besides, I don't see any issue due to slight miss-synchronizat= ion of the realm-reports between two agents since they should still repre= sent the realm load more or less accurately. >>>>>>> Also if the agents are not synchronized and if they are playin= g the role of DOIC reacting node then they will apply abatement algorithm= based on different values (for the same realm). So it does not matter if= the client does the same. >>>>>>> Finally, I don't see any value-add of using the "identity of >>>>>>> the node that sends the realm-report" to discard the other report= >>>>>>> related to the same realm. In other words, this same logic can be= >>>>>>> achieved using sequence-numbers as well, i.e. when the >>>>>>> overload-report of an realm is active, the client is going to >>>>>>> ignore all the reports of the same realm which has lower sequence= >>>>>>> number value. So in essence, when two agents are sending >>>>>>> realm-reports, one of the reports is automatically ignored by the= >>>>>>> client if their sequence numbers differ. So the outcome without >>>>>>> including the "identity if the node that sends realm report" is >>>>>>> same as >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>>> Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descr= iption: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take th= e role of a reporting node for realm-routed-request reports, reacting nod= es may receive in different answer messages different realm-routed-reques= t type OLRs inserted by the different reporting nodes. Although it is exp= ected that the different reporting nodes report more or less the same con= tent, it cannot be expected that reports are 100% synchronized. Especiall= y sequence numbers may differ. To allow reacting nodes correctly detect o= utdates/replays/freshness of OLRs in this scenario, it is proposed that r= ealm-routed-request type OLRs are extended to contain the Diameter Identi= ty of the reporting node that inserted the realm-routed-request type OLR.= (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Repo= rting nodes that insert realm-routed-request type OLRs to answer messages= MUST also insert their Diameter Identity. Reacting nodes MUST take the D= iameter Identity received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP on= ly required for realm reports. It would not be required for host reports= as the identity of the sender of the host report is implicitly defined b= y the origin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update exist= ing state. To this end I propose that we add wording that for the durati= on of a realm report, the reacting node only listens for updates to the r= ealm report from from the DOIC node that sent the realm report that resul= ted in the realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will o= nly listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> _________________________________________________________________= >>>>>>> _ _______________________________________________________ >>>>>>> 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'expedit= eur et le detruire ainsi que les pieces jointes. Les messages electroniqu= es etant susceptibles d'alteration, Orange decline toute responsabilite s= i 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 sende= r 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. >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> 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 >> >> ______________________________________________________________________= >> ___________________________________________________ >> >> 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 q= ue les pieces jointes. Les messages electroniques etant susceptibles d'al= teration, 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 b= e 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. >> >> _______________________________________________ >> 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 nobody Wed Aug 6 08:22:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D64E1B2811 for ; Wed, 6 Aug 2014 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz6uUbdyR57M for ; Wed, 6 Aug 2014 08:22:36 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074B51B27BF for ; Wed, 6 Aug 2014 08:22:35 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50210 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XF32t-0007Sa-Cl; Wed, 06 Aug 2014 08:22:34 -0700 Message-ID: <53E24837.9080501@usdonovans.com> Date: Wed, 06 Aug 2014 10:22:31 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Nirav Salot (nsalot)" , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lOzrsQZ8VwLbEcc8mgPz4uqCIJs Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 15:22:39 -0000 Lionel, No one is saying that an agent cannot be upgraded to support DOIC. What I did say was that it is not reasonable to expect existing agents,=20 those deployed before DOIC is defined, to be able to support DOIC. Steve On 8/6/14, 8:19 AM, lionel.morand@orange.com wrote: > Hi, > > In order to try to conclude on the fact that an agent modifying the Ori= gin-host AVP can only be a proxy agent and then such a proxy can be upgra= ded to deal with DOIC: > > >From RFC6733: > > 6.3. Origin-Host AVP > > The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and= > it MUST be present in all Diameter messages. This AVP identifies t= he > endpoint that originated the Diameter message. > > <<< Relay agents MUST NOT modify this AVP. >>> > > The value of the Origin-Host AVP is guaranteed to be unique within = a > single host. > > Note that the Origin-Host AVP may resolve to more than one address = as > the Diameter peer may support more than one address. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > Regards, > > Lionel > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsa= lot) > Envoy=E9 : mardi 5 ao=FBt 2014 19:51 > =C0 : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) > > Steve, > > What is so difficult here and not sure why two operators are involved s= ince the proposal is restricted to change of behavior in either the host = or the agent at operator B? > Operator B has two choices: > - Turn off topology hiding in its agent since agents are not supporting= DOIC yet. > - Turn off generation of overload report at the host since topology hid= ing is important. > > These are configuration related issue and interim/transient problems - = until the agents are upgraded to support DOIC. > So I don't think we need protocol solution for these types of problems.= > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Tuesday, August 05, 2014 5:47 PM > To: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > How does operator A tell operator B to turn off topology hiding in oper= ator B's network? > > Keep in mind as well that topology hiding is just one example of a feat= ure that would require an agent to change the origin-host in answer messa= ges. There may be others. We need to solve the general problem and, if = possible, solve it through signalling, not configuration. > > Steve > > On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >> Exactly what I said :-) >> Topology hiding is a non-issue. It is just a matter of configuration. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Nirav Salot (nsalot) a =E9crit ---- >> >> >> +1 >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >> (Susan) >> Sent: Tuesday, August 05, 2014 8:06 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Hello Ben, >> >> Putting S1 node in the OLR would break the principle of topology hidin= g. If this is what the operator could accept, what's the benefit to have = the agent on the route to do the topology hiding? >> >> >From my point of view, there are other ways to solve the problem: >> >> - If the hosts behind the agent can be enhanced to support overload co= ntrol, the agent should be enhanced to support overload control, or be en= hanced to just discard the OLR AVP. >> - Or by configuration disable the topology hiding functionality of the= agent since it does not make sense if the S1 could indicate its node ide= ntity to the client in the OLR. >> - Or by configuration, the hosts behind the agent should know that the= agent does not support overload control, then don't send OLR to the clie= nt. >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, August 05, 2014 6:32 AM >> To: Shishufeng (Susan) >> Cc: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Let me try to rephrase the problem: >> >> Consider the following scenario: >> >> S1 >> / >> C---P--S2 >> \ >> S3 >> >> "P" is a diameter proxy that does _not_ support DOIC, and performs top= ology hiding. The client and servers do support DOIC. >> >> Assume S1 becomes overloaded. It sends an host OLR with a reduction pe= rcentage of 100% in an answer to a request sent by C. The answer has an O= rigin-Host of "S1". >> >> P receives the answer, and changes Origin-Host to "P". Since P does no= t support DOIC, it treats the OLR as an "unknown AVP", and forwards it un= changed. >> >> C receives the report, and and entirely stops sending traffic to P. >> (As far as C knows, P is the server.) >> >> This is not the desired behavior. RFC7068 Req 17 says the following. T= he behavior in this example clearly violates the MUST NOT: >> >>> REQ 17: In a mixed environment with nodes that support the solut= ion >>> and nodes that do not, the solution MUST NOT result in >>> materially less useful throughput during overload as wou= ld >>> have resulted if the solution were not present. It SHOU= LD >>> result in less severe overload in this environment. >>> >> If, on the other hand, the OLR internally identified the overloaded no= de as "S1", C would at least know that it can't do anything useful with t= he OLR, since it doesn't know about S1 due to the topology hiding at P. I= n this case, it just ignores the OLR. That still violates the SHOULD, but= at least does not violate the MUST NOT. >> >> >> >> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >> >>> Hello, >>> >>> I really don't understand the logic for the host to insert its own id= entity into the overload report. Wouldn't it be the host to report its ow= n overload report in an answer message to the client? Why we need the age= nt to do anything in this case? >>> >>> To say the least, if the host can insert its identity into the messag= e, what's the benefit to have the agent for topology hiding? >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Saturday, August 02, 2014 3:54 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Yes, it could be either. The critical point is that the overloaded h= ost is indicated by the diameter id in the overload report, not the origi= n-host AVP. >>> >>> Steve >>> >>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>> I don't think you can conflate "host that generated this OLR" with >>>> "host that is overloaded". It's perfectly valid for them to not be >>>> the same thing, even for host reports. (But I'd be happy to include= >>>> both.) >>>> >>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>> >>>>> Somewhat on on the path toward generalization, we have a second iss= ue currently open that can be solved by having the DOIC node that inserts= an overload report in an answer message include it's own diameter identi= ty in the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origi= n-Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to cha= nge the origin-host in answer messages. One example of where this is don= e is in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports= =2E >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group A= VP that carries the diameter identity of the DOIC node that inserted the = overload report into the answer message. Issue #66 points out the need i= n host reports and issue #58 points out the need in realm reports. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wro= te: >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the sa= me vendor and use a proprietary communication protocol to synchronize the= host report. Or, if a multiple (redundant or active-active) load-balanci= ng agents are generating the report, they must similarly be synchronized.= >>>>>>> Is seems like including the host name per Ulrich's suggestion = is a simple way of avoiding proprietary mechanisms or coupling between ho= sts and agents. >>>>>>> In some applications, the hosts can be completely decoupled (agno= stic about each other). I think it would be poor to add a synchronization= requirement just to support DOIC. >>>>>>> -Dave >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>> lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>>> with Nirav's view. >>>>>>> Regards, >>>>>>> Lionel >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this iss= ue, >>>>>>> I don't agree to include identity of the DOIC node that sends the= report, into the realm reports. >>>>>>> In my view, the issue mentioned below - of two agents not 100%= synchronize w.r.t the realm-report - is the related to "how agents synch= ronized between themselves" and since that is not standardized we should = not be developing protocol solution for the case which occurs due to this= out-of-standards solution. >>>>>>> Besides, I don't see any issue due to slight miss-synchronizat= ion of the realm-reports between two agents since they should still repre= sent the realm load more or less accurately. >>>>>>> Also if the agents are not synchronized and if they are playin= g the role of DOIC reacting node then they will apply abatement algorithm= based on different values (for the same realm). So it does not matter if= the client does the same. >>>>>>> Finally, I don't see any value-add of using the "identity of >>>>>>> the node that sends the realm-report" to discard the other report= >>>>>>> related to the same realm. In other words, this same logic can be= >>>>>>> achieved using sequence-numbers as well, i.e. when the >>>>>>> overload-report of an realm is active, the client is going to >>>>>>> ignore all the reports of the same realm which has lower sequence= >>>>>>> number value. So in essence, when two agents are sending >>>>>>> realm-reports, one of the reports is automatically ignored by the= >>>>>>> client if their sequence numbers differ. So the outcome without >>>>>>> including the "identity if the node that sends realm report" is >>>>>>> same as >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>>> Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders = of realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descr= iption: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take th= e role of a reporting node for realm-routed-request reports, reacting nod= es may receive in different answer messages different realm-routed-reques= t type OLRs inserted by the different reporting nodes. Although it is exp= ected that the different reporting nodes report more or less the same con= tent, it cannot be expected that reports are 100% synchronized. Especiall= y sequence numbers may differ. To allow reacting nodes correctly detect o= utdates/replays/freshness of OLRs in this scenario, it is proposed that r= ealm-routed-request type OLRs are extended to contain the Diameter Identi= ty of the reporting node that inserted the realm-routed-request type OLR.= (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Repo= rting nodes that insert realm-routed-request type OLRs to answer messages= MUST also insert their Diameter Identity. Reacting nodes MUST take the D= iameter Identity received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity = of the DOIC node that sends the report. This would be an optional AVP on= ly required for realm reports. It would not be required for host reports= as the identity of the sender of the host report is implicitly defined b= y the origin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be = used to determine if a received report is ignored or used to update exist= ing state. To this end I propose that we add wording that for the durati= on of a realm report, the reacting node only listens for updates to the r= ealm report from from the DOIC node that sent the realm report that resul= ted in the realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will o= nly listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> _________________________________________________________________= >>>>>>> _ _______________________________________________________ >>>>>>> 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'expedit= eur et le detruire ainsi que les pieces jointes. Les messages electroniqu= es etant susceptibles d'alteration, Orange decline toute responsabilite s= i 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 sende= r 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. >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> 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 >> >> ______________________________________________________________________= >> ___________________________________________________ >> >> 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 q= ue les pieces jointes. Les messages electroniques etant susceptibles d'al= teration, 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 b= e 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. >> >> _______________________________________________ >> 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 > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Wed Aug 6 08:29:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6D1B2830 for ; Wed, 6 Aug 2014 08:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXII3U-_-THb for ; Wed, 6 Aug 2014 08:29:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C031B282D for ; Wed, 6 Aug 2014 08:29:37 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id B0DD01B8632; Wed, 6 Aug 2014 17:29:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 8BA3415804E; Wed, 6 Aug 2014 17:29:35 +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.03.0181.006; Wed, 6 Aug 2014 17:29:35 +0200 From: To: Steve Donovan , "Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u7+ZEAgAAOQgCAAIGHAIAEYa6AgABEAwCAACafAIAASycZgAAwnoCAAF2IgIABZnFQgAACRYCAACG8kA== Date: Wed, 6 Aug 2014 15:29:34 +0000 Message-ID: <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E24837.9080501@usdonovans.com> In-Reply-To: <53E24837.9080501@usdonovans.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.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.123022 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/brC30MTk4M_-zWo5sfdtc57A7-I Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 15:29:44 -0000 Hi Steve, In that case it would mean that the proxy would not be any more compliant w= ith the application it is supposed to support and advertise in CER/CEA. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mercredi 6 ao=FBt 2014 17:23 =C0=A0: MORAND Lionel IMT/OLN; Nirav Salot (nsalot); dime@ietf.org Objet=A0: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) Lionel, No one is saying that an agent cannot be upgraded to support DOIC. What I did say was that it is not reasonable to expect existing agents, tho= se deployed before DOIC is defined, to be able to support DOIC. Steve On 8/6/14, 8:19 AM, lionel.morand@orange.com wrote: > Hi, > > In order to try to conclude on the fact that an agent modifying the Origi= n-host AVP can only be a proxy agent and then such a proxy can be upgraded = to deal with DOIC: > > >From RFC6733: > > 6.3. Origin-Host AVP > > The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and > it MUST be present in all Diameter messages. This AVP identifies the > endpoint that originated the Diameter message. > > <<< Relay agents MUST NOT modify this AVP. >>> > > The value of the Origin-Host AVP is guaranteed to be unique within a > single host. > > Note that the Origin-Host AVP may resolve to more than one address as > the Diameter peer may support more than one address. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > Regards, > > Lionel > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot=20 > (nsalot) Envoy=E9 : mardi 5 ao=FBt 2014 19:51 =C0 : Steve Donovan;=20 > dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports (was=20 > Re: DOIC issue #58 Proposal) > > Steve, > > What is so difficult here and not sure why two operators are involved sin= ce the proposal is restricted to change of behavior in either the host or t= he agent at operator B? > Operator B has two choices: > - Turn off topology hiding in its agent since agents are not supporting D= OIC yet. > - Turn off generation of overload report at the host since topology hidin= g is important. > > These are configuration related issue and interim/transient problems - un= til the agents are upgraded to support DOIC. > So I don't think we need protocol solution for these types of problems. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Tuesday, August 05, 2014 5:47 PM > To: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > How does operator A tell operator B to turn off topology hiding in operat= or B's network? > > Keep in mind as well that topology hiding is just one example of a featur= e that would require an agent to change the origin-host in answer messages.= There may be others. We need to solve the general problem and, if possib= le, solve it through signalling, not configuration. > > Steve > > On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >> Exactly what I said :-) >> Topology hiding is a non-issue. It is just a matter of configuration. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Nirav Salot (nsalot) a =E9crit ---- >> >> >> +1 >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >> (Susan) >> Sent: Tuesday, August 05, 2014 8:06 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> Hello Ben, >> >> Putting S1 node in the OLR would break the principle of topology hiding.= If this is what the operator could accept, what's the benefit to have the = agent on the route to do the topology hiding? >> >> >From my point of view, there are other ways to solve the problem: >> >> - If the hosts behind the agent can be enhanced to support overload cont= rol, the agent should be enhanced to support overload control, or be enhanc= ed to just discard the OLR AVP. >> - Or by configuration disable the topology hiding functionality of the a= gent since it does not make sense if the S1 could indicate its node identit= y to the client in the OLR. >> - Or by configuration, the hosts behind the agent should know that the a= gent does not support overload control, then don't send OLR to the client. >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, August 05, 2014 6:32 AM >> To: Shishufeng (Susan) >> Cc: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> Let me try to rephrase the problem: >> >> Consider the following scenario: >> >> S1 >> / >> C---P--S2 >> \ >> S3 >> >> "P" is a diameter proxy that does _not_ support DOIC, and performs topol= ogy hiding. The client and servers do support DOIC. >> >> Assume S1 becomes overloaded. It sends an host OLR with a reduction perc= entage of 100% in an answer to a request sent by C. The answer has an Origi= n-Host of "S1". >> >> P receives the answer, and changes Origin-Host to "P". Since P does not = support DOIC, it treats the OLR as an "unknown AVP", and forwards it unchan= ged. >> >> C receives the report, and and entirely stops sending traffic to P. >> (As far as C knows, P is the server.) >> >> This is not the desired behavior. RFC7068 Req 17 says the following. The= behavior in this example clearly violates the MUST NOT: >> >>> REQ 17: In a mixed environment with nodes that support the solution >>> and nodes that do not, the solution MUST NOT result in >>> materially less useful throughput during overload as would >>> have resulted if the solution were not present. It SHOULD >>> result in less severe overload in this environment. >>> >> If, on the other hand, the OLR internally identified the overloaded node= as "S1", C would at least know that it can't do anything useful with the O= LR, since it doesn't know about S1 due to the topology hiding at P. In this= case, it just ignores the OLR. That still violates the SHOULD, but at leas= t does not violate the MUST NOT. >> >> >> >> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >> >>> Hello, >>> >>> I really don't understand the logic for the host to insert its own iden= tity into the overload report. Wouldn't it be the host to report its own ov= erload report in an answer message to the client? Why we need the agent to = do anything in this case? >>> >>> To say the least, if the host can insert its identity into the message,= what's the benefit to have the agent for topology hiding? >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Saturday, August 02, 2014 3:54 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>> >>> Yes, it could be either. The critical point is that the overloaded hos= t is indicated by the diameter id in the overload report, not the origin-ho= st AVP. >>> >>> Steve >>> >>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>> I don't think you can conflate "host that generated this OLR" with=20 >>>> "host that is overloaded". It's perfectly valid for them to not be=20 >>>> the same thing, even for host reports. (But I'd be happy to=20 >>>> include >>>> both.) >>>> >>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>>> >>>>> Somewhat on on the path toward generalization, we have a second issue= currently open that can be solved by having the DOIC node that inserts an = overload report in an answer message include it's own diameter identity in = the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-= Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to chang= e the origin-host in answer messages. One example of where this is done is= in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports. >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group AVP= that carries the diameter identity of the DOIC node that inserted the over= load report into the answer message. Issue #66 points out the need in host= reports and issue #58 points out the need in realm reports. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the same= vendor and use a proprietary communication protocol to synchronize the hos= t report. Or, if a multiple (redundant or active-active) load-balancing age= nts are generating the report, they must similarly be synchronized. >>>>>>> Is seems like including the host name per Ulrich's suggestion is= a simple way of avoiding proprietary mechanisms or coupling between hosts = and agents. >>>>>>> In some applications, the hosts can be completely decoupled (agnost= ic about each other). I think it would be poor to add a synchronization req= uirement just to support DOIC. >>>>>>> -Dave >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>> lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>>>> with Nirav's view. >>>>>>> Regards, >>>>>>> Lionel >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this=20 >>>>>>> issue, I don't agree to include identity of the DOIC node that send= s the report, into the realm reports. >>>>>>> In my view, the issue mentioned below - of two agents not 100% s= ynchronize w.r.t the realm-report - is the related to "how agents synchroni= zed between themselves" and since that is not standardized we should not be= developing protocol solution for the case which occurs due to this out-of-= standards solution. >>>>>>> Besides, I don't see any issue due to slight miss-synchronizatio= n of the realm-reports between two agents since they should still represent= the realm load more or less accurately. >>>>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm bas= ed on different values (for the same realm). So it does not matter if the c= lient does the same. >>>>>>> Finally, I don't see any value-add of using the "identity of=20 >>>>>>> the node that sends the realm-report" to discard the other=20 >>>>>>> report related to the same realm. In other words, this same=20 >>>>>>> logic can be achieved using sequence-numbers as well, i.e. when=20 >>>>>>> the overload-report of an realm is active, the client is going=20 >>>>>>> to ignore all the reports of the same realm which has lower=20 >>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>> ignored by the client if their sequence numbers differ. So the=20 >>>>>>> outcome without including the "identity if the node that sends=20 >>>>>>> realm report" is same as >>>>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>>> Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders of= realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descrip= tion: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting nodes m= ay receive in different answer messages different realm-routed-request type= OLRs inserted by the different reporting nodes. Although it is expected th= at the different reporting nodes report more or less the same content, it c= annot be expected that reports are 100% synchronized. Especially sequence n= umbers may differ. To allow reacting nodes correctly detect outdates/replay= s/freshness of OLRs in this scenario, it is proposed that realm-routed-requ= est type OLRs are extended to contain the Diameter Identity of the reportin= g node that inserted the realm-routed-request type OLR. (e.g. as already pr= oposed in draft-donovan-dime-agent-overload-01). Reporting nodes that inser= t realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity received = within the OLR into account in order to detect outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity of= the DOIC node that sends the report. This would be an optional AVP only r= equired for realm reports. It would not be required for host reports as th= e identity of the sender of the host report is implicitly defined by the or= igin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be us= ed to determine if a received report is ignored or used to update existing = state. To this end I propose that we add wording that for the duration of = a realm report, the reacting node only listens for updates to the realm rep= ort from from the DOIC node that sent the realm report that resulted in the= realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> _ _ _______________________________________________________ >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'expe= diteur et le detruire ainsi que les pieces jointes. Les messages electroniq= ues 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=20 >>>>>>> privileged information that may be protected by law; they should no= t 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 ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> 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 >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Aug 6 09:14:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69A1A03F1 for ; Wed, 6 Aug 2014 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txVcLdDKPnhy for ; Wed, 6 Aug 2014 09:14:03 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBA01A000F for ; Wed, 6 Aug 2014 09:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18656; q=dns/txt; s=iport; t=1407341644; x=1408551244; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kgeJRCRR6fEmHPbALwgA1W6dVHaSL02clSNU3gEnt3E=; b=OoYBi5pcy/6Xz1w1GJ/9EF77s8UhcZ/YcWFXTOHqbryGJsAiKWdT9hkt t7m1sKfJ2u7lzrYnvFZ48vU72UyehJUAmE9Rw6pne80lRTT2PWRFBlAl6 qQGXzwpIqcQ+VwkuNcEcYdNhTa+F5p+sdpacYXgJaxFwD5Et0vWQoAl7T 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAOdS4lOtJA2E/2dsb2JhbABRCYMNUlcEzBwKh0gBgRQWd4QDAQEBBAEBAWQHFwQCAQgOAwQBAQEKCxIHJwsUCQgCBAESCBOIJw3DJBMEjAqCYAcKAQ4ROAYEgyWBHAWKWY0LmRODVGyBBgcXIg X-IronPort-AV: E=Sophos;i="5.01,812,1400025600"; d="scan'208";a="67024684" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 06 Aug 2014 16:14:03 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s76GE1mQ027850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 16:14:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 11:14:01 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8buoAgAAOQgCAAIGHAIAEYa6AgABEAwD//9LCkIAAfXwAgABSJoCAAAh+QIABu/oA//+7ZlA= Date: Wed, 6 Aug 2014 16:14:01 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <53E246BA.6000202@usdonovans.com> In-Reply-To: <53E246BA.6000202@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.30] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/55joxRThVF10mkdXaBXGOvWIKs0 Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 16:14:07 -0000 Steve, Thanks for pointing out a different scenario. But for me, nothing changes y= et. The operator 1 and operator 2 will get in special agreement to share the ov= erload report across operator's boundary. As part of the same, (since the o= perator 2 does not fully support DOIC yet) the hosts in the operator 1 is c= onfigured to not include the overload report in the answer messages going t= owards the operator 2. Or alternatively, the edge agents at operator 1 remo= ve those overload reports. Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, August 06, 2014 8:46 PM To: Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Nirav, Here's the cross operator scenario: Operator 1 Operator 2 | | +--+ | |S1| | /+--+ | / +-+ +-+ | +-+ / +--+ |C|-------|A|---|----|A|-----|S2| +-+ +-+ | +-+ \ +--+ | \ | \+--+ | |S3| | +--+ Operator 1 is fully DOIC capable. The agent in operator 2's network is not DOIC enabled. The servers in operator 2's network are DOIC enabled. All traffic from operator 1 targeted for operator 2 flows through operator = 2's agent. The agent in operator 2's network changes the origin-host header, maybe for= topology hiding reasons, maybe for other reasons. C sends a request that is routed to S1. The request includes the OC-Suppor= ted-Features AVP. S1 is overloaded and sends a response with an overload report requesting a = reduction in traffic. In the worst case S1 can send an overload report wit= h a request for a 100% reduction in traffic. C will see this as coming from the identity inserted by operator 2's agent = and, as a result will throttle 100% of traffic targeted for operator 2's ne= twork despite there being two fully operational servers in operator 2's net= work. While it may be in operator 2's best interest to upgrade their agent to sup= port DOIC, operator 1 has no ability to make that upgrade happen. Steve On 8/5/14, 12:51 PM, Nirav Salot (nsalot) wrote: > Steve, > > What is so difficult here and not sure why two operators are involved sin= ce the proposal is restricted to change of behavior in either the host or t= he agent at operator B? > Operator B has two choices: > - Turn off topology hiding in its agent since agents are not supporting D= OIC yet. > - Turn off generation of overload report at the host since topology hidin= g is important. > > These are configuration related issue and interim/transient problems - un= til the agents are upgraded to support DOIC. > So I don't think we need protocol solution for these types of problems. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Tuesday, August 05, 2014 5:47 PM > To: dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > How does operator A tell operator B to turn off topology hiding in operat= or B's network? > > Keep in mind as well that topology hiding is just one example of a featur= e that would require an agent to change the origin-host in answer messages.= There may be others. We need to solve the general problem and, if possib= le, solve it through signalling, not configuration. > > Steve > > On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >> Exactly what I said :-) >> Topology hiding is a non-issue. It is just a matter of configuration. >> >> Lionel >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Nirav Salot (nsalot) a =E9crit ---- >> >> >> +1 >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >> (Susan) >> Sent: Tuesday, August 05, 2014 8:06 AM >> To: Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> Hello Ben, >> >> Putting S1 node in the OLR would break the principle of topology hiding.= If this is what the operator could accept, what's the benefit to have the = agent on the route to do the topology hiding? >> >> >From my point of view, there are other ways to solve the problem: >> >> - If the hosts behind the agent can be enhanced to support overload cont= rol, the agent should be enhanced to support overload control, or be enhanc= ed to just discard the OLR AVP. >> - Or by configuration disable the topology hiding functionality of the a= gent since it does not make sense if the S1 could indicate its node identit= y to the client in the OLR. >> - Or by configuration, the hosts behind the agent should know that the a= gent does not support overload control, then don't send OLR to the client. >> >> Best Regards, >> Susan >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, August 05, 2014 6:32 AM >> To: Shishufeng (Susan) >> Cc: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> Let me try to rephrase the problem: >> >> Consider the following scenario: >> >> S1 >> / >> C---P--S2 >> \ >> S3 >> >> "P" is a diameter proxy that does _not_ support DOIC, and performs topol= ogy hiding. The client and servers do support DOIC. >> >> Assume S1 becomes overloaded. It sends an host OLR with a reduction perc= entage of 100% in an answer to a request sent by C. The answer has an Origi= n-Host of "S1". >> >> P receives the answer, and changes Origin-Host to "P". Since P does not = support DOIC, it treats the OLR as an "unknown AVP", and forwards it unchan= ged. >> >> C receives the report, and and entirely stops sending traffic to P. >> (As far as C knows, P is the server.) >> >> This is not the desired behavior. RFC7068 Req 17 says the following. The= behavior in this example clearly violates the MUST NOT: >> >>> REQ 17: In a mixed environment with nodes that support the solutio= n >>> and nodes that do not, the solution MUST NOT result in >>> materially less useful throughput during overload as would >>> have resulted if the solution were not present. It SHOULD >>> result in less severe overload in this environment. >>> >> If, on the other hand, the OLR internally identified the overloaded node= as "S1", C would at least know that it can't do anything useful with the O= LR, since it doesn't know about S1 due to the topology hiding at P. In this= case, it just ignores the OLR. That still violates the SHOULD, but at leas= t does not violate the MUST NOT. >> >> >> >> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >> >>> Hello, >>> >>> I really don't understand the logic for the host to insert its own iden= tity into the overload report. Wouldn't it be the host to report its own ov= erload report in an answer message to the client? Why we need the agent to = do anything in this case? >>> >>> To say the least, if the host can insert its identity into the message,= what's the benefit to have the agent for topology hiding? >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Saturday, August 02, 2014 3:54 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>> >>> Yes, it could be either. The critical point is that the overloaded hos= t is indicated by the diameter id in the overload report, not the origin-ho= st AVP. >>> >>> Steve >>> >>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>> I don't think you can conflate "host that generated this OLR" with=20 >>>> "host that is overloaded". It's perfectly valid for them to not be=20 >>>> the same thing, even for host reports. (But I'd be happy to=20 >>>> include >>>> both.) >>>> >>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>>> >>>>> Somewhat on on the path toward generalization, we have a second issue= currently open that can be solved by having the DOIC node that inserts an = overload report in an answer message include it's own diameter identity in = the overload report. >>>>> >>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-= Host. >>>>> >>>>> This issue points out that existing non DOIC agents are able to chang= e the origin-host in answer messages. One example of where this is done is= in topology hiding implementations. >>>>> >>>>> This issue can be addressed through attribution of overload reports. >>>>> >>>>> As such, I propose that we add a required AVP to the OC-OLR group AVP= that carries the diameter identity of the DOIC node that inserted the over= load report into the answer message. Issue #66 points out the need in host= reports and issue #58 points out the need in realm reports. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>> +1 (modulo my comment to generalize) >>>>>> >>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote= : >>>>>> >>>>>>> I believe Nirav's view requires all hosts in a realm to be the same= vendor and use a proprietary communication protocol to synchronize the hos= t report. Or, if a multiple (redundant or active-active) load-balancing age= nts are generating the report, they must similarly be synchronized. >>>>>>> Is seems like including the host name per Ulrich's suggestion is= a simple way of avoiding proprietary mechanisms or coupling between hosts = and agents. >>>>>>> In some applications, the hosts can be completely decoupled (agnost= ic about each other). I think it would be poor to add a synchronization req= uirement just to support DOIC. >>>>>>> -Dave >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>> lionel.morand@orange.com >>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>>>> with Nirav's view. >>>>>>> Regards, >>>>>>> Lionel >>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this=20 >>>>>>> issue, I don't agree to include identity of the DOIC node that send= s the report, into the realm reports. >>>>>>> In my view, the issue mentioned below - of two agents not 100% s= ynchronize w.r.t the realm-report - is the related to "how agents synchroni= zed between themselves" and since that is not standardized we should not be= developing protocol solution for the case which occurs due to this out-of-= standards solution. >>>>>>> Besides, I don't see any issue due to slight miss-synchronizatio= n of the realm-reports between two agents since they should still represent= the realm load more or less accurately. >>>>>>> Also if the agents are not synchronized and if they are playing = the role of DOIC reacting node then they will apply abatement algorithm bas= ed on different values (for the same realm). So it does not matter if the c= lient does the same. >>>>>>> Finally, I don't see any value-add of using the "identity of=20 >>>>>>> the node that sends the realm-report" to discard the other=20 >>>>>>> report related to the same realm. In other words, this same=20 >>>>>>> logic can be achieved using sequence-numbers as well, i.e. when=20 >>>>>>> the overload-report of an realm is active, the client is going=20 >>>>>>> to ignore all the reports of the same realm which has lower=20 >>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>> ignored by the client if their sequence numbers differ. So the=20 >>>>>>> outcome without including the "identity if the node that sends=20 >>>>>>> realm report" is same as >>>>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>>>>> Regards, >>>>>>> Nirav. >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>>>>> Donovan >>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>> To: dime@ietf.org >>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>> >>>>>>> Issue #58 deals with the fact that there can be multiple senders of= realm overload report for the same realm. >>>>>>> >>>>>>> Ulrich proposes one aspect of what is required in the issue descrip= tion: >>>>>>> >>>>>>> "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting nodes m= ay receive in different answer messages different realm-routed-request type= OLRs inserted by the different reporting nodes. Although it is expected th= at the different reporting nodes report more or less the same content, it c= annot be expected that reports are 100% synchronized. Especially sequence n= umbers may differ. To allow reacting nodes correctly detect outdates/replay= s/freshness of OLRs in this scenario, it is proposed that realm-routed-requ= est type OLRs are extended to contain the Diameter Identity of the reportin= g node that inserted the realm-routed-request type OLR. (e.g. as already pr= oposed in draft-donovan-dime-agent-overload-01). Reporting nodes that inser= t realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity received = within the OLR into account in order to detect outdates/replays/freshness." >>>>>>> >>>>>>> I agree with Ulrich that realm reports must include the identity of= the DOIC node that sends the report. This would be an optional AVP only r= equired for realm reports. It would not be required for host reports as th= e identity of the sender of the host report is implicitly defined by the or= igin-host in the answer message. >>>>>>> >>>>>>> I also agree that the Diameter Identity of the reporting node be us= ed to determine if a received report is ignored or used to update existing = state. To this end I propose that we add wording that for the duration of = a realm report, the reacting node only listens for updates to the realm rep= ort from from the DOIC node that sent the realm report that resulted in the= realm OCS being stored. >>>>>>> >>>>>>> The effect should be that the reacting node will accept a realm rep= ort from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> _ _ _______________________________________________________ >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'expe= diteur et le detruire ainsi que les pieces jointes. Les messages electroniq= ues 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=20 >>>>>>> privileged information that may be protected by law; they should no= t 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 ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> 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 >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Aug 6 09:55:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D380C1A03A1 for ; Wed, 6 Aug 2014 09:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfdNHBW1kl3l for ; Wed, 6 Aug 2014 09:55:22 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194841A036D for ; Wed, 6 Aug 2014 09:55:22 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50451 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XF4Uc-0000eA-Ni; Wed, 06 Aug 2014 09:55:20 -0700 Message-ID: <53E25DF2.5040606@usdonovans.com> Date: Wed, 06 Aug 2014 11:55:14 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Nirav Salot (nsalot)" , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E24837.9080501@usdonovans.com> <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XId1icNul9auVIrE7IdgVGfKupA Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 16:55:31 -0000 This is a backwards compatibility scenario. The proxy-agent can be 100% compatible with the n-1 version of the=20 application that does not include DOIC support and still advertise=20 support for that application. I am not familiar with a mechanism for advertising support for a=20 specific version of the application without changing the application-id=20 itself. Have I missed something? Are you proposing changing the=20 application-id for all applications that support DOIC? Steve On 8/6/14, 10:29 AM, lionel.morand@orange.com wrote: > Hi Steve, > > In that case it would mean that the proxy would not be any more complia= nt with the application it is supposed to support and advertise in CER/CE= A. > > Regards, > > Lionel > > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoy=E9 : mercredi 6 ao=FBt 2014 17:23 > =C0 : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); dime@ietf.org > Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue = #58 Proposal) > > Lionel, > > No one is saying that an agent cannot be upgraded to support DOIC. > > What I did say was that it is not reasonable to expect existing agents,= those deployed before DOIC is defined, to be able to support DOIC. > > Steve > > On 8/6/14, 8:19 AM, lionel.morand@orange.com wrote: >> Hi, >> >> In order to try to conclude on the fact that an agent modifying the Or= igin-host AVP can only be a proxy agent and then such a proxy can be upgr= aded to deal with DOIC: >> >> >From RFC6733: >> >> 6.3. Origin-Host AVP >> >> The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, a= nd >> it MUST be present in all Diameter messages. This AVP identifies= the >> endpoint that originated the Diameter message. >> >> <<< Relay agents MUST NOT modify this AVP. >>> >> >> The value of the Origin-Host AVP is guaranteed to be unique withi= n a >> single host. >> >> Note that the Origin-Host AVP may resolve to more than one addres= s as >> the Diameter peer may support more than one address. >> >> This AVP SHOULD be placed as close to the Diameter header as >> possible. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >> (nsalot) Envoy=E9 : mardi 5 ao=FBt 2014 19:51 =C0 : Steve Donovan; >> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports (was >> Re: DOIC issue #58 Proposal) >> >> Steve, >> >> What is so difficult here and not sure why two operators are involved = since the proposal is restricted to change of behavior in either the host= or the agent at operator B? >> Operator B has two choices: >> - Turn off topology hiding in its agent since agents are not supportin= g DOIC yet. >> - Turn off generation of overload report at the host since topology hi= ding is important. >> >> These are configuration related issue and interim/transient problems -= until the agents are upgraded to support DOIC. >> So I don't think we need protocol solution for these types of problems= =2E >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Tuesday, August 05, 2014 5:47 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> How does operator A tell operator B to turn off topology hiding in ope= rator B's network? >> >> Keep in mind as well that topology hiding is just one example of a fea= ture that would require an agent to change the origin-host in answer mess= ages. There may be others. We need to solve the general problem and, if= possible, solve it through signalling, not configuration. >> >> Steve >> >> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>> Exactly what I said :-) >>> Topology hiding is a non-issue. It is just a matter of configuration.= >>> >>> Lionel >>> >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> >>> >>> +1 >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>> (Susan) >>> Sent: Tuesday, August 05, 2014 8:06 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Hello Ben, >>> >>> Putting S1 node in the OLR would break the principle of topology hidi= ng. If this is what the operator could accept, what's the benefit to have= the agent on the route to do the topology hiding? >>> >>> >From my point of view, there are other ways to solve the problem: >>> >>> - If the hosts behind the agent can be enhanced to support overload c= ontrol, the agent should be enhanced to support overload control, or be e= nhanced to just discard the OLR AVP. >>> - Or by configuration disable the topology hiding functionality of th= e agent since it does not make sense if the S1 could indicate its node id= entity to the client in the OLR. >>> - Or by configuration, the hosts behind the agent should know that th= e agent does not support overload control, then don't send OLR to the cli= ent. >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Tuesday, August 05, 2014 6:32 AM >>> To: Shishufeng (Susan) >>> Cc: Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Let me try to rephrase the problem: >>> >>> Consider the following scenario: >>> >>> S1 >>> / >>> C---P--S2 >>> \ >>> S3 >>> >>> "P" is a diameter proxy that does _not_ support DOIC, and performs to= pology hiding. The client and servers do support DOIC. >>> >>> Assume S1 becomes overloaded. It sends an host OLR with a reduction p= ercentage of 100% in an answer to a request sent by C. The answer has an = Origin-Host of "S1". >>> >>> P receives the answer, and changes Origin-Host to "P". Since P does n= ot support DOIC, it treats the OLR as an "unknown AVP", and forwards it u= nchanged. >>> >>> C receives the report, and and entirely stops sending traffic to P. >>> (As far as C knows, P is the server.) >>> >>> This is not the desired behavior. RFC7068 Req 17 says the following. = The behavior in this example clearly violates the MUST NOT: >>> >>>> REQ 17: In a mixed environment with nodes that support the sol= ution >>>> and nodes that do not, the solution MUST NOT result in= >>>> materially less useful throughput during overload as w= ould >>>> have resulted if the solution were not present. It SH= OULD >>>> result in less severe overload in this environment. >>>> >>> If, on the other hand, the OLR internally identified the overloaded n= ode as "S1", C would at least know that it can't do anything useful with = the OLR, since it doesn't know about S1 due to the topology hiding at P. = In this case, it just ignores the OLR. That still violates the SHOULD, bu= t at least does not violate the MUST NOT. >>> >>> >>> >>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >>> >>>> Hello, >>>> >>>> I really don't understand the logic for the host to insert its own i= dentity into the overload report. Wouldn't it be the host to report its o= wn overload report in an answer message to the client? Why we need the ag= ent to do anything in this case? >>>> >>>> To say the least, if the host can insert its identity into the messa= ge, what's the benefit to have the agent for topology hiding? >>>> >>>> Best Regards, >>>> Susan >>>> >>>> -----Original Message----- >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Saturday, August 02, 2014 3:54 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>> >>>> Yes, it could be either. The critical point is that the overloaded = host is indicated by the diameter id in the overload report, not the orig= in-host AVP. >>>> >>>> Steve >>>> >>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>> I don't think you can conflate "host that generated this OLR" with >>>>> "host that is overloaded". It's perfectly valid for them to not be >>>>> the same thing, even for host reports. (But I'd be happy to >>>>> include >>>>> both.) >>>>> >>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>>> >>>>>> Somewhat on on the path toward generalization, we have a second is= sue currently open that can be solved by having the DOIC node that insert= s an overload report in an answer message include it's own diameter ident= ity in the overload report. >>>>>> >>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Orig= in-Host. >>>>>> >>>>>> This issue points out that existing non DOIC agents are able to ch= ange the origin-host in answer messages. One example of where this is do= ne is in topology hiding implementations. >>>>>> >>>>>> This issue can be addressed through attribution of overload report= s. >>>>>> >>>>>> As such, I propose that we add a required AVP to the OC-OLR group = AVP that carries the diameter identity of the DOIC node that inserted the= overload report into the answer message. Issue #66 points out the need = in host reports and issue #58 points out the need in realm reports. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>> +1 (modulo my comment to generalize) >>>>>>> >>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wr= ote: >>>>>>> >>>>>>>> I believe Nirav's view requires all hosts in a realm to be the s= ame vendor and use a proprietary communication protocol to synchronize th= e host report. Or, if a multiple (redundant or active-active) load-balanc= ing agents are generating the report, they must similarly be synchronized= =2E >>>>>>>> Is seems like including the host name per Ulrich's suggestio= n is a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>>>>>>> In some applications, the hosts can be completely decoupled (agn= ostic about each other). I think it would be poor to add a synchronizatio= n requirement just to support DOIC. >>>>>>>> -Dave >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>>> lionel.morand@orange.com >>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>>>> with Nirav's view. >>>>>>>> Regards, >>>>>>>> Lionel >>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this >>>>>>>> issue, I don't agree to include identity of the DOIC node that s= ends the report, into the realm reports. >>>>>>>> In my view, the issue mentioned below - of two agents not 10= 0% synchronize w.r.t the realm-report - is the related to "how agents syn= chronized between themselves" and since that is not standardized we shoul= d not be developing protocol solution for the case which occurs due to th= is out-of-standards solution. >>>>>>>> Besides, I don't see any issue due to slight miss-synchroniz= ation of the realm-reports between two agents since they should still rep= resent the realm load more or less accurately. >>>>>>>> Also if the agents are not synchronized and if they are play= ing the role of DOIC reacting node then they will apply abatement algorit= hm based on different values (for the same realm). So it does not matter = if the client does the same. >>>>>>>> Finally, I don't see any value-add of using the "identity of= >>>>>>>> the node that sends the realm-report" to discard the other >>>>>>>> report related to the same realm. In other words, this same >>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when >>>>>>>> the overload-report of an realm is active, the client is going >>>>>>>> to ignore all the reports of the same realm which has lower >>>>>>>> sequence number value. So in essence, when two agents are >>>>>>>> sending realm-reports, one of the reports is automatically >>>>>>>> ignored by the client if their sequence numbers differ. So the >>>>>>>> outcome without including the "identity if the node that sends >>>>>>>> realm report" is same as >>>>>>>>> The effect should be that the reacting node will accept a realm= report from anyone when there is no active OLR for the realm but it will= only listen to one reporting node when it has an active report. >>>>>>>> Regards, >>>>>>>> Nirav. >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve= >>>>>>>> Donovan >>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>> >>>>>>>> Issue #58 deals with the fact that there can be multiple senders= of realm overload report for the same realm. >>>>>>>> >>>>>>>> Ulrich proposes one aspect of what is required in the issue desc= ription: >>>>>>>> >>>>>>>> "In deployments where more than one node is configured to take t= he role of a reporting node for realm-routed-request reports, reacting no= des may receive in different answer messages different realm-routed-reque= st type OLRs inserted by the different reporting nodes. Although it is ex= pected that the different reporting nodes report more or less the same co= ntent, it cannot be expected that reports are 100% synchronized. Especial= ly sequence numbers may differ. To allow reacting nodes correctly detect = outdates/replays/freshness of OLRs in this scenario, it is proposed that = realm-routed-request type OLRs are extended to contain the Diameter Ident= ity of the reporting node that inserted the realm-routed-request type OLR= =2E (e.g. as already proposed in draft-donovan-dime-agent-overload-01). R= eporting nodes that insert realm-routed-request type OLRs to answer messa= ges MUST also insert their Diameter Identity. Reacting nodes MUST take th= e Diameter Identity received within the OLR into account in order to dete= ct outdates/replays/freshness." >>>>>>>> >>>>>>>> I agree with Ulrich that realm reports must include the identity= of the DOIC node that sends the report. This would be an optional AVP o= nly required for realm reports. It would not be required for host report= s as the identity of the sender of the host report is implicitly defined = by the origin-host in the answer message. >>>>>>>> >>>>>>>> I also agree that the Diameter Identity of the reporting node be= used to determine if a received report is ignored or used to update exis= ting state. To this end I propose that we add wording that for the durat= ion of a realm report, the reacting node only listens for updates to the = realm report from from the DOIC node that sent the realm report that resu= lted in the realm OCS being stored. >>>>>>>> >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> ________________________________________________________________= >>>>>>>> _ _ _______________________________________________________ >>>>>>>> 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'e= xpediteur et le detruire ainsi que les pieces jointes. Les messages elect= roniques etant susceptibles d'alteration, Orange decline toute responsabi= lite 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 send= er 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. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> 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 >>> >>> _____________________________________________________________________= >>> _ ___________________________________________________ >>> >>> 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'a= lteration, 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 an= d 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. >>> >>> _______________________________________________ >>> 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 >> >> ______________________________________________________________________= >> ___________________________________________________ >> >> 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 q= ue les pieces jointes. Les messages electroniques etant susceptibles d'al= teration, 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 b= e 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. >> >> > > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s 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 b= een modified, changed or falsified. > Thank you. > > From nobody Wed Aug 6 10:01:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3291A0AFA for ; Wed, 6 Aug 2014 10:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYjn0_LGhMY3 for ; Wed, 6 Aug 2014 10:01:31 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6901D1A03EC for ; Wed, 6 Aug 2014 10:01:30 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50454 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XF4ad-0007m7-20; Wed, 06 Aug 2014 10:01:28 -0700 Message-ID: <53E25F67.2090703@usdonovans.com> Date: Wed, 06 Aug 2014 12:01:27 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <53E246BA.6000202@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xfWxkUEfE2g66i8eQmKRESa8tyU Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 17:01:36 -0000 Nirav, All, It seems like we at least have agreement that an agent that changes=20 Origin-Host, for whatever reason, can result in clients abating too much = traffic routed through that agent. The worst case is that this could=20 result in 100% of traffic targeted for the Diameter Identity inserted by = the agent being throttled. We have two solutions proposed: 1) A signaling based solution that would allow reacting nodes to know=20 that an "origin-host-munging" agent was in the path of the message. 2) An administrative based solution involving turning off=20 "origin-host-munging" behavior in agents until the agent is upgraded to=20 fully supports DOIC. Is this a correct summary of where we are so far on this issue? Steve On 8/6/14, 11:14 AM, Nirav Salot (nsalot) wrote: > Steve, > > Thanks for pointing out a different scenario. But for me, nothing chang= es yet. > The operator 1 and operator 2 will get in special agreement to share th= e overload report across operator's boundary. As part of the same, (since= the operator 2 does not fully support DOIC yet) the hosts in the operato= r 1 is configured to not include the overload report in the answer messag= es going towards the operator 2. Or alternatively, the edge agents at ope= rator 1 remove those overload reports. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 06, 2014 8:46 PM > To: Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > Nirav, > > Here's the cross operator scenario: > > Operator 1 Operator 2 > | > | +--+ > | |S1| > | /+--+ > | / > +-+ +-+ | +-+ / +--+ > |C|-------|A|---|----|A|-----|S2| > +-+ +-+ | +-+ \ +--+ > | \ > | \+--+ > | |S3| > | +--+ > > > Operator 1 is fully DOIC capable. > > The agent in operator 2's network is not DOIC enabled. > > The servers in operator 2's network are DOIC enabled. > > All traffic from operator 1 targeted for operator 2 flows through opera= tor 2's agent. > > The agent in operator 2's network changes the origin-host header, maybe= for topology hiding reasons, maybe for other reasons. > > C sends a request that is routed to S1. The request includes the OC-Su= pported-Features AVP. > > S1 is overloaded and sends a response with an overload report requestin= g a reduction in traffic. In the worst case S1 can send an overload repo= rt with a request for a 100% reduction in traffic. > > C will see this as coming from the identity inserted by operator 2's ag= ent and, as a result will throttle 100% of traffic targeted for operator = 2's network despite there being two fully operational servers in operator= 2's network. > > While it may be in operator 2's best interest to upgrade their agent to= support DOIC, operator 1 has no ability to make that upgrade happen. > > Steve > > > On 8/5/14, 12:51 PM, Nirav Salot (nsalot) wrote: >> Steve, >> >> What is so difficult here and not sure why two operators are involved = since the proposal is restricted to change of behavior in either the host= or the agent at operator B? >> Operator B has two choices: >> - Turn off topology hiding in its agent since agents are not supportin= g DOIC yet. >> - Turn off generation of overload report at the host since topology hi= ding is important. >> >> These are configuration related issue and interim/transient problems -= until the agents are upgraded to support DOIC. >> So I don't think we need protocol solution for these types of problems= =2E >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Tuesday, August 05, 2014 5:47 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> How does operator A tell operator B to turn off topology hiding in ope= rator B's network? >> >> Keep in mind as well that topology hiding is just one example of a fea= ture that would require an agent to change the origin-host in answer mess= ages. There may be others. We need to solve the general problem and, if= possible, solve it through signalling, not configuration. >> >> Steve >> >> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>> Exactly what I said :-) >>> Topology hiding is a non-issue. It is just a matter of configuration.= >>> >>> Lionel >>> >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> >>> >>> +1 >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>> (Susan) >>> Sent: Tuesday, August 05, 2014 8:06 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Hello Ben, >>> >>> Putting S1 node in the OLR would break the principle of topology hidi= ng. If this is what the operator could accept, what's the benefit to have= the agent on the route to do the topology hiding? >>> >>> >From my point of view, there are other ways to solve the problem: >>> >>> - If the hosts behind the agent can be enhanced to support overload c= ontrol, the agent should be enhanced to support overload control, or be e= nhanced to just discard the OLR AVP. >>> - Or by configuration disable the topology hiding functionality of th= e agent since it does not make sense if the S1 could indicate its node id= entity to the client in the OLR. >>> - Or by configuration, the hosts behind the agent should know that th= e agent does not support overload control, then don't send OLR to the cli= ent. >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Tuesday, August 05, 2014 6:32 AM >>> To: Shishufeng (Susan) >>> Cc: Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> Let me try to rephrase the problem: >>> >>> Consider the following scenario: >>> >>> S1 >>> / >>> C---P--S2 >>> \ >>> S3 >>> >>> "P" is a diameter proxy that does _not_ support DOIC, and performs to= pology hiding. The client and servers do support DOIC. >>> >>> Assume S1 becomes overloaded. It sends an host OLR with a reduction p= ercentage of 100% in an answer to a request sent by C. The answer has an = Origin-Host of "S1". >>> >>> P receives the answer, and changes Origin-Host to "P". Since P does n= ot support DOIC, it treats the OLR as an "unknown AVP", and forwards it u= nchanged. >>> >>> C receives the report, and and entirely stops sending traffic to P. >>> (As far as C knows, P is the server.) >>> >>> This is not the desired behavior. RFC7068 Req 17 says the following. = The behavior in this example clearly violates the MUST NOT: >>> >>>> REQ 17: In a mixed environment with nodes that support the sol= ution >>>> and nodes that do not, the solution MUST NOT result in= >>>> materially less useful throughput during overload as w= ould >>>> have resulted if the solution were not present. It SH= OULD >>>> result in less severe overload in this environment. >>>> >>> If, on the other hand, the OLR internally identified the overloaded n= ode as "S1", C would at least know that it can't do anything useful with = the OLR, since it doesn't know about S1 due to the topology hiding at P. = In this case, it just ignores the OLR. That still violates the SHOULD, bu= t at least does not violate the MUST NOT. >>> >>> >>> >>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >>> >>>> Hello, >>>> >>>> I really don't understand the logic for the host to insert its own i= dentity into the overload report. Wouldn't it be the host to report its o= wn overload report in an answer message to the client? Why we need the ag= ent to do anything in this case? >>>> >>>> To say the least, if the host can insert its identity into the messa= ge, what's the benefit to have the agent for topology hiding? >>>> >>>> Best Regards, >>>> Susan >>>> >>>> -----Original Message----- >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Saturday, August 02, 2014 3:54 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>> >>>> Yes, it could be either. The critical point is that the overloaded = host is indicated by the diameter id in the overload report, not the orig= in-host AVP. >>>> >>>> Steve >>>> >>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>> I don't think you can conflate "host that generated this OLR" with >>>>> "host that is overloaded". It's perfectly valid for them to not be >>>>> the same thing, even for host reports. (But I'd be happy to >>>>> include >>>>> both.) >>>>> >>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>>> >>>>>> Somewhat on on the path toward generalization, we have a second is= sue currently open that can be solved by having the DOIC node that insert= s an overload report in an answer message include it's own diameter ident= ity in the overload report. >>>>>> >>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Orig= in-Host. >>>>>> >>>>>> This issue points out that existing non DOIC agents are able to ch= ange the origin-host in answer messages. One example of where this is do= ne is in topology hiding implementations. >>>>>> >>>>>> This issue can be addressed through attribution of overload report= s. >>>>>> >>>>>> As such, I propose that we add a required AVP to the OC-OLR group = AVP that carries the diameter identity of the DOIC node that inserted the= overload report into the answer message. Issue #66 points out the need = in host reports and issue #58 points out the need in realm reports. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>> +1 (modulo my comment to generalize) >>>>>>> >>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wr= ote: >>>>>>> >>>>>>>> I believe Nirav's view requires all hosts in a realm to be the s= ame vendor and use a proprietary communication protocol to synchronize th= e host report. Or, if a multiple (redundant or active-active) load-balanc= ing agents are generating the report, they must similarly be synchronized= =2E >>>>>>>> Is seems like including the host name per Ulrich's suggestio= n is a simple way of avoiding proprietary mechanisms or coupling between = hosts and agents. >>>>>>>> In some applications, the hosts can be completely decoupled (agn= ostic about each other). I think it would be poor to add a synchronizatio= n requirement just to support DOIC. >>>>>>>> -Dave >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>>> lionel.morand@orange.com >>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>>>> with Nirav's view. >>>>>>>> Regards, >>>>>>>> Lionel >>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this >>>>>>>> issue, I don't agree to include identity of the DOIC node that s= ends the report, into the realm reports. >>>>>>>> In my view, the issue mentioned below - of two agents not 10= 0% synchronize w.r.t the realm-report - is the related to "how agents syn= chronized between themselves" and since that is not standardized we shoul= d not be developing protocol solution for the case which occurs due to th= is out-of-standards solution. >>>>>>>> Besides, I don't see any issue due to slight miss-synchroniz= ation of the realm-reports between two agents since they should still rep= resent the realm load more or less accurately. >>>>>>>> Also if the agents are not synchronized and if they are play= ing the role of DOIC reacting node then they will apply abatement algorit= hm based on different values (for the same realm). So it does not matter = if the client does the same. >>>>>>>> Finally, I don't see any value-add of using the "identity of= >>>>>>>> the node that sends the realm-report" to discard the other >>>>>>>> report related to the same realm. In other words, this same >>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when >>>>>>>> the overload-report of an realm is active, the client is going >>>>>>>> to ignore all the reports of the same realm which has lower >>>>>>>> sequence number value. So in essence, when two agents are >>>>>>>> sending realm-reports, one of the reports is automatically >>>>>>>> ignored by the client if their sequence numbers differ. So the >>>>>>>> outcome without including the "identity if the node that sends >>>>>>>> realm report" is same as >>>>>>>>> The effect should be that the reacting node will accept a realm= report from anyone when there is no active OLR for the realm but it will= only listen to one reporting node when it has an active report. >>>>>>>> Regards, >>>>>>>> Nirav. >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve= >>>>>>>> Donovan >>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>> >>>>>>>> Issue #58 deals with the fact that there can be multiple senders= of realm overload report for the same realm. >>>>>>>> >>>>>>>> Ulrich proposes one aspect of what is required in the issue desc= ription: >>>>>>>> >>>>>>>> "In deployments where more than one node is configured to take t= he role of a reporting node for realm-routed-request reports, reacting no= des may receive in different answer messages different realm-routed-reque= st type OLRs inserted by the different reporting nodes. Although it is ex= pected that the different reporting nodes report more or less the same co= ntent, it cannot be expected that reports are 100% synchronized. Especial= ly sequence numbers may differ. To allow reacting nodes correctly detect = outdates/replays/freshness of OLRs in this scenario, it is proposed that = realm-routed-request type OLRs are extended to contain the Diameter Ident= ity of the reporting node that inserted the realm-routed-request type OLR= =2E (e.g. as already proposed in draft-donovan-dime-agent-overload-01). R= eporting nodes that insert realm-routed-request type OLRs to answer messa= ges MUST also insert their Diameter Identity. Reacting nodes MUST take th= e Diameter Identity received within the OLR into account in order to dete= ct outdates/replays/freshness." >>>>>>>> >>>>>>>> I agree with Ulrich that realm reports must include the identity= of the DOIC node that sends the report. This would be an optional AVP o= nly required for realm reports. It would not be required for host report= s as the identity of the sender of the host report is implicitly defined = by the origin-host in the answer message. >>>>>>>> >>>>>>>> I also agree that the Diameter Identity of the reporting node be= used to determine if a received report is ignored or used to update exis= ting state. To this end I propose that we add wording that for the durat= ion of a realm report, the reacting node only listens for updates to the = realm report from from the DOIC node that sent the realm report that resu= lted in the realm OCS being stored. >>>>>>>> >>>>>>>> The effect should be that the reacting node will accept a realm = report from anyone when there is no active OLR for the realm but it will = only listen to one reporting node when it has an active report. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> ________________________________________________________________= >>>>>>>> _ _ _______________________________________________________ >>>>>>>> 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'e= xpediteur et le detruire ainsi que les pieces jointes. Les messages elect= roniques etant susceptibles d'alteration, Orange decline toute responsabi= lite 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 send= er 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. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> 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 >>> >>> _____________________________________________________________________= >>> _ ___________________________________________________ >>> >>> 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'a= lteration, 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 an= d 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. >>> >>> _______________________________________________ >>> 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 nobody Wed Aug 6 10:05:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014851A0383 for ; Wed, 6 Aug 2014 10:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtBQ2NVrjjLI for ; Wed, 6 Aug 2014 10:05:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135F31A0B0C for ; Wed, 6 Aug 2014 10:05:26 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3763F2AC841; Wed, 6 Aug 2014 19:05:24 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 1C5B1180053; Wed, 6 Aug 2014 19:05:24 +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.03.0181.006; Wed, 6 Aug 2014 19:05:23 +0200 From: To: Steve Donovan , "Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/4yHmvnNMdUmSf2artj0z55u7+ZEAgAAOQgCAAIGHAIAEYa6AgABEAwCAACafAIAASycZgAAwnoCAAF2IgIABZnFQgAACRYCAACG8kP//+CwAgAAiRmA= Date: Wed, 6 Aug 2014 17:05:22 +0000 Message-ID: <24059_1407344724_53E26054_24059_1751_1_6B7134B31289DC4FAF731D844122B36E6956E4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53DA9EA2.4010906@usdonovans.com>, <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E24837.9080501@usdonovans.com> <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E25DF2.5040606@usdonovans.com> In-Reply-To: <53E25DF2.5040606@usdonovans.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.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.123022 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OIY5YizzhmcbqQ7NGhWLfZ8bdWg Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 17:05:40 -0000 Hi Steve, There are several ways to avoid the problem of backward incompatibility and= changing the application-id is one of them. In 3GPP, we are using the Supported-Features AVP for the same purpose and t= he OC-Feature-Vector is introduced in this draft for the same reason i.e. d= iscover what a node is supporting at the application level without changing= the application-id. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mercredi 6 ao=FBt 2014 18:55 =C0=A0: MORAND Lionel IMT/OLN; Nirav Salot (nsalot); dime@ietf.org Objet=A0: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #5= 8 Proposal) This is a backwards compatibility scenario. The proxy-agent can be 100% compatible with the n-1 version of the applicat= ion that does not include DOIC support and still advertise support for that= application. I am not familiar with a mechanism for advertising support for a specific v= ersion of the application without changing the application-id itself. Have= I missed something? Are you proposing changing the application-id for all= applications that support DOIC? Steve On 8/6/14, 10:29 AM, lionel.morand@orange.com wrote: > Hi Steve, > > In that case it would mean that the proxy would not be any more compliant= with the application it is supposed to support and advertise in CER/CEA. > > Regards, > > Lionel > > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mercredi= =20 > 6 ao=FBt 2014 17:23 =C0 : MORAND Lionel IMT/OLN; Nirav Salot (nsalot);=20 > dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports (was=20 > Re: DOIC issue #58 Proposal) > > Lionel, > > No one is saying that an agent cannot be upgraded to support DOIC. > > What I did say was that it is not reasonable to expect existing agents, t= hose deployed before DOIC is defined, to be able to support DOIC. > > Steve > > On 8/6/14, 8:19 AM, lionel.morand@orange.com wrote: >> Hi, >> >> In order to try to conclude on the fact that an agent modifying the Orig= in-host AVP can only be a proxy agent and then such a proxy can be upgraded= to deal with DOIC: >> >> >From RFC6733: >> >> 6.3. Origin-Host AVP >> >> The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and >> it MUST be present in all Diameter messages. This AVP identifies t= he >> endpoint that originated the Diameter message. >> >> <<< Relay agents MUST NOT modify this AVP. >>> >> >> The value of the Origin-Host AVP is guaranteed to be unique within a >> single host. >> >> Note that the Origin-Host AVP may resolve to more than one address = as >> the Diameter peer may support more than one address. >> >> This AVP SHOULD be placed as close to the Diameter header as >> possible. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >> (nsalot) Envoy=E9 : mardi 5 ao=FBt 2014 19:51 =C0 : Steve Donovan;=20 >> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports (was >> Re: DOIC issue #58 Proposal) >> >> Steve, >> >> What is so difficult here and not sure why two operators are involved si= nce the proposal is restricted to change of behavior in either the host or = the agent at operator B? >> Operator B has two choices: >> - Turn off topology hiding in its agent since agents are not supporting = DOIC yet. >> - Turn off generation of overload report at the host since topology hidi= ng is important. >> >> These are configuration related issue and interim/transient problems - u= ntil the agents are upgraded to support DOIC. >> So I don't think we need protocol solution for these types of problems. >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Tuesday, August 05, 2014 5:47 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> How does operator A tell operator B to turn off topology hiding in opera= tor B's network? >> >> Keep in mind as well that topology hiding is just one example of a featu= re that would require an agent to change the origin-host in answer messages= . There may be others. We need to solve the general problem and, if possi= ble, solve it through signalling, not configuration. >> >> Steve >> >> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>> Exactly what I said :-) >>> Topology hiding is a non-issue. It is just a matter of configuration. >>> >>> Lionel >>> >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> >>> >>> +1 >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>> (Susan) >>> Sent: Tuesday, August 05, 2014 8:06 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>> >>> Hello Ben, >>> >>> Putting S1 node in the OLR would break the principle of topology hiding= . If this is what the operator could accept, what's the benefit to have the= agent on the route to do the topology hiding? >>> >>> >From my point of view, there are other ways to solve the problem: >>> >>> - If the hosts behind the agent can be enhanced to support overload con= trol, the agent should be enhanced to support overload control, or be enhan= ced to just discard the OLR AVP. >>> - Or by configuration disable the topology hiding functionality of the = agent since it does not make sense if the S1 could indicate its node identi= ty to the client in the OLR. >>> - Or by configuration, the hosts behind the agent should know that the = agent does not support overload control, then don't send OLR to the client. >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Tuesday, August 05, 2014 6:32 AM >>> To: Shishufeng (Susan) >>> Cc: Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>> >>> Let me try to rephrase the problem: >>> >>> Consider the following scenario: >>> >>> S1 >>> / >>> C---P--S2 >>> \ >>> S3 >>> >>> "P" is a diameter proxy that does _not_ support DOIC, and performs topo= logy hiding. The client and servers do support DOIC. >>> >>> Assume S1 becomes overloaded. It sends an host OLR with a reduction per= centage of 100% in an answer to a request sent by C. The answer has an Orig= in-Host of "S1". >>> >>> P receives the answer, and changes Origin-Host to "P". Since P does not= support DOIC, it treats the OLR as an "unknown AVP", and forwards it uncha= nged. >>> >>> C receives the report, and and entirely stops sending traffic to P. >>> (As far as C knows, P is the server.) >>> >>> This is not the desired behavior. RFC7068 Req 17 says the following. Th= e behavior in this example clearly violates the MUST NOT: >>> >>>> REQ 17: In a mixed environment with nodes that support the solut= ion >>>> and nodes that do not, the solution MUST NOT result in >>>> materially less useful throughput during overload as wou= ld >>>> have resulted if the solution were not present. It SHOU= LD >>>> result in less severe overload in this environment. >>>> >>> If, on the other hand, the OLR internally identified the overloaded nod= e as "S1", C would at least know that it can't do anything useful with the = OLR, since it doesn't know about S1 due to the topology hiding at P. In thi= s case, it just ignores the OLR. That still violates the SHOULD, but at lea= st does not violate the MUST NOT. >>> >>> >>> >>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >>> >>>> Hello, >>>> >>>> I really don't understand the logic for the host to insert its own ide= ntity into the overload report. Wouldn't it be the host to report its own o= verload report in an answer message to the client? Why we need the agent to= do anything in this case? >>>> >>>> To say the least, if the host can insert its identity into the message= , what's the benefit to have the agent for topology hiding? >>>> >>>> Best Regards, >>>> Susan >>>> >>>> -----Original Message----- >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Saturday, August 02, 2014 3:54 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>>> issue #58 Proposal) >>>> >>>> Yes, it could be either. The critical point is that the overloaded ho= st is indicated by the diameter id in the overload report, not the origin-h= ost AVP. >>>> >>>> Steve >>>> >>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>> I don't think you can conflate "host that generated this OLR" with=20 >>>>> "host that is overloaded". It's perfectly valid for them to not be=20 >>>>> the same thing, even for host reports. (But I'd be happy to=20 >>>>> include >>>>> both.) >>>>> >>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>>>> >>>>>> Somewhat on on the path toward generalization, we have a second issu= e currently open that can be solved by having the DOIC node that inserts an= overload report in an answer message include it's own diameter identity in= the overload report. >>>>>> >>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin= -Host. >>>>>> >>>>>> This issue points out that existing non DOIC agents are able to chan= ge the origin-host in answer messages. One example of where this is done i= s in topology hiding implementations. >>>>>> >>>>>> This issue can be addressed through attribution of overload reports. >>>>>> >>>>>> As such, I propose that we add a required AVP to the OC-OLR group AV= P that carries the diameter identity of the DOIC node that inserted the ove= rload report into the answer message. Issue #66 points out the need in hos= t reports and issue #58 points out the need in realm reports. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>> +1 (modulo my comment to generalize) >>>>>>> >>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrot= e: >>>>>>> >>>>>>>> I believe Nirav's view requires all hosts in a realm to be the sam= e vendor and use a proprietary communication protocol to synchronize the ho= st report. Or, if a multiple (redundant or active-active) load-balancing ag= ents are generating the report, they must similarly be synchronized. >>>>>>>> Is seems like including the host name per Ulrich's suggestion = is a simple way of avoiding proprietary mechanisms or coupling between host= s and agents. >>>>>>>> In some applications, the hosts can be completely decoupled (agnos= tic about each other). I think it would be poor to add a synchronization re= quirement just to support DOIC. >>>>>>>> -Dave >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>> lionel.morand@orange.com >>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>>>>> with Nirav's view. >>>>>>>> Regards, >>>>>>>> Lionel >>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this=20 >>>>>>>> issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. >>>>>>>> In my view, the issue mentioned below - of two agents not 100%= synchronize w.r.t the realm-report - is the related to "how agents synchro= nized between themselves" and since that is not standardized we should not = be developing protocol solution for the case which occurs due to this out-o= f-standards solution. >>>>>>>> Besides, I don't see any issue due to slight miss-synchronizat= ion of the realm-reports between two agents since they should still represe= nt the realm load more or less accurately. >>>>>>>> Also if the agents are not synchronized and if they are playin= g the role of DOIC reacting node then they will apply abatement algorithm b= ased on different values (for the same realm). So it does not matter if the= client does the same. >>>>>>>> Finally, I don't see any value-add of using the "identity=20 >>>>>>>> of the node that sends the realm-report" to discard the other=20 >>>>>>>> report related to the same realm. In other words, this same=20 >>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when=20 >>>>>>>> the overload-report of an realm is active, the client is going=20 >>>>>>>> to ignore all the reports of the same realm which has lower=20 >>>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>>> ignored by the client if their sequence numbers differ. So the=20 >>>>>>>> outcome without including the "identity if the node that sends=20 >>>>>>>> realm report" is same as >>>>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>>>>>> Regards, >>>>>>>> Nirav. >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>> Steve Donovan >>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>> >>>>>>>> Issue #58 deals with the fact that there can be multiple senders o= f realm overload report for the same realm. >>>>>>>> >>>>>>>> Ulrich proposes one aspect of what is required in the issue descri= ption: >>>>>>>> >>>>>>>> "In deployments where more than one node is configured to take the= role of a reporting node for realm-routed-request reports, reacting nodes = may receive in different answer messages different realm-routed-request typ= e OLRs inserted by the different reporting nodes. Although it is expected t= hat the different reporting nodes report more or less the same content, it = cannot be expected that reports are 100% synchronized. Especially sequence = numbers may differ. To allow reacting nodes correctly detect outdates/repla= ys/freshness of OLRs in this scenario, it is proposed that realm-routed-req= uest type OLRs are extended to contain the Diameter Identity of the reporti= ng node that inserted the realm-routed-request type OLR. (e.g. as already p= roposed in draft-donovan-dime-agent-overload-01). Reporting nodes that inse= rt realm-routed-request type OLRs to answer messages MUST also insert their= Diameter Identity. Reacting nodes MUST take the Diameter Identity received= within the OLR into account in order to detect outdates/replays/freshness." >>>>>>>> >>>>>>>> I agree with Ulrich that realm reports must include the identity o= f the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports as t= he identity of the sender of the host report is implicitly defined by the o= rigin-host in the answer message. >>>>>>>> >>>>>>>> I also agree that the Diameter Identity of the reporting node be u= sed to determine if a received report is ignored or used to update existing= state. To this end I propose that we add wording that for the duration of= a realm report, the reacting node only listens for updates to the realm re= port from from the DOIC node that sent the realm report that resulted in th= e realm OCS being stored. >>>>>>>> >>>>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________________________ >>>>>>>> _ _ _ _______________________________________________________ >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'exp= editeur et le detruire ainsi que les pieces jointes. Les messages electroni= ques etant susceptibles d'alteration, Orange decline toute responsabilite s= i ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>> This message and its attachments may contain confidential=20 >>>>>>>> or privileged information that may be protected by law; they shoul= d 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 h= ave been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> 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 >>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Aug 6 10:25:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B991A0452 for ; Wed, 6 Aug 2014 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2y6fpYuRJP4 for ; Wed, 6 Aug 2014 10:25:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF7E1A0389 for ; Wed, 6 Aug 2014 10:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20627; q=dns/txt; s=iport; t=1407345929; x=1408555529; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=64Wf+6ZGXjfER/DQXJA8k10XcgUP731Whnuu4C1y5bQ=; b=O0xNS7g+KBvNyUGqLyNPO426LCSoV86mJhEN3yuFu4I8N2EAXD1W/2Yc u5VDxAnUodL3FH02Mb6FXti5fDJp2nWHSY5zxg6gAT9n8SUy5pHmIFYKi XpAlOnuii2/wkD7l3r6vi8cnYkYK0IfaDO7XrrFlTGWw9rEgzFQa3GqJV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFABlk4lOtJV2b/2dsb2JhbABRCYMNUlcEzBwKh0gBgRQWd4QDAQEBBAEBAWQHFwQCAQgOAwQBAQEKCxIHJwsUCQgCBAESCBOIJw3DTRMEjAqCYAcKAQ4ROAYEgyWBHAWKWY0LmRODVGyBBgcXIg X-IronPort-AV: E=Sophos;i="5.01,813,1400025600"; d="scan'208";a="67037275" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 06 Aug 2014 17:25:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s76HPQVX013910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 17:25:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 12:25:25 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8buoAgAAOQgCAAIGHAIAEYa6AgABEAwD//9LCkIAAfXwAgABSJoCAAAh+QIABu/oA//+7ZlCAAGIEgP//sGDg Date: Wed, 6 Aug 2014 17:25:22 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <53E246BA.6000202@usdonovans.com> <53E25F67.2090703@usdonovans.com> In-Reply-To: <53E25F67.2090703@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.30] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gsg8cMb2QBJ6Sk2jOrc9WwZ0US0 Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 17:25:33 -0000 Steve, To be honest, I don't think 1 below - of including identity of the host in = the report - can be considered as solution here since it has multiple issue= s: - It breaks the topology hiding. So basically introduction of new feature b= reaks the existing feature and hence I don't think it is acceptable.=20 - Finally the client discards the overload report so I am not sure what goo= d we achieved here as compared to turning off the feature at the source its= elf. Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, August 06, 2014 10:31 PM To: Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) Nirav, All, It seems like we at least have agreement that an agent that changes Origin-= Host, for whatever reason, can result in clients abating too much traffic r= outed through that agent. The worst case is that this could result in 100%= of traffic targeted for the Diameter Identity inserted by the agent being = throttled. We have two solutions proposed: 1) A signaling based solution that would allow reacting nodes to know that = an "origin-host-munging" agent was in the path of the message. 2) An administrative based solution involving turning off "origin-host-mung= ing" behavior in agents until the agent is upgraded to fully supports DOIC. Is this a correct summary of where we are so far on this issue? Steve On 8/6/14, 11:14 AM, Nirav Salot (nsalot) wrote: > Steve, > > Thanks for pointing out a different scenario. But for me, nothing changes= yet. > The operator 1 and operator 2 will get in special agreement to share the = overload report across operator's boundary. As part of the same, (since the= operator 2 does not fully support DOIC yet) the hosts in the operator 1 is= configured to not include the overload report in the answer messages going= towards the operator 2. Or alternatively, the edge agents at operator 1 re= move those overload reports. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 06, 2014 8:46 PM > To: Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 > issue #58 Proposal) > > Nirav, > > Here's the cross operator scenario: > > Operator 1 Operator 2 > | > | +--+ > | |S1| > | /+--+ > | / > +-+ +-+ | +-+ / +--+ > |C|-------|A|---|----|A|-----|S2| > +-+ +-+ | +-+ \ +--+ > | \ > | \+--+ > | |S3| > | +--+ > > > Operator 1 is fully DOIC capable. > > The agent in operator 2's network is not DOIC enabled. > > The servers in operator 2's network are DOIC enabled. > > All traffic from operator 1 targeted for operator 2 flows through operato= r 2's agent. > > The agent in operator 2's network changes the origin-host header, maybe f= or topology hiding reasons, maybe for other reasons. > > C sends a request that is routed to S1. The request includes the OC-Supp= orted-Features AVP. > > S1 is overloaded and sends a response with an overload report requesting = a reduction in traffic. In the worst case S1 can send an overload report w= ith a request for a 100% reduction in traffic. > > C will see this as coming from the identity inserted by operator 2's agen= t and, as a result will throttle 100% of traffic targeted for operator 2's = network despite there being two fully operational servers in operator 2's n= etwork. > > While it may be in operator 2's best interest to upgrade their agent to s= upport DOIC, operator 1 has no ability to make that upgrade happen. > > Steve > > > On 8/5/14, 12:51 PM, Nirav Salot (nsalot) wrote: >> Steve, >> >> What is so difficult here and not sure why two operators are involved si= nce the proposal is restricted to change of behavior in either the host or = the agent at operator B? >> Operator B has two choices: >> - Turn off topology hiding in its agent since agents are not supporting = DOIC yet. >> - Turn off generation of overload report at the host since topology hidi= ng is important. >> >> These are configuration related issue and interim/transient problems - u= ntil the agents are upgraded to support DOIC. >> So I don't think we need protocol solution for these types of problems. >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Tuesday, August 05, 2014 5:47 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >> >> How does operator A tell operator B to turn off topology hiding in opera= tor B's network? >> >> Keep in mind as well that topology hiding is just one example of a featu= re that would require an agent to change the origin-host in answer messages= . There may be others. We need to solve the general problem and, if possi= ble, solve it through signalling, not configuration. >> >> Steve >> >> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>> Exactly what I said :-) >>> Topology hiding is a non-issue. It is just a matter of configuration. >>> >>> Lionel >>> >>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>> >>> ---- Nirav Salot (nsalot) a =E9crit ---- >>> >>> >>> +1 >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>> (Susan) >>> Sent: Tuesday, August 05, 2014 8:06 AM >>> To: Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>> >>> Hello Ben, >>> >>> Putting S1 node in the OLR would break the principle of topology hiding= . If this is what the operator could accept, what's the benefit to have the= agent on the route to do the topology hiding? >>> >>> >From my point of view, there are other ways to solve the problem: >>> >>> - If the hosts behind the agent can be enhanced to support overload con= trol, the agent should be enhanced to support overload control, or be enhan= ced to just discard the OLR AVP. >>> - Or by configuration disable the topology hiding functionality of the = agent since it does not make sense if the S1 could indicate its node identi= ty to the client in the OLR. >>> - Or by configuration, the hosts behind the agent should know that the = agent does not support overload control, then don't send OLR to the client. >>> >>> Best Regards, >>> Susan >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Tuesday, August 05, 2014 6:32 AM >>> To: Shishufeng (Susan) >>> Cc: Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>> >>> Let me try to rephrase the problem: >>> >>> Consider the following scenario: >>> >>> S1 >>> / >>> C---P--S2 >>> \ >>> S3 >>> >>> "P" is a diameter proxy that does _not_ support DOIC, and performs topo= logy hiding. The client and servers do support DOIC. >>> >>> Assume S1 becomes overloaded. It sends an host OLR with a reduction per= centage of 100% in an answer to a request sent by C. The answer has an Orig= in-Host of "S1". >>> >>> P receives the answer, and changes Origin-Host to "P". Since P does not= support DOIC, it treats the OLR as an "unknown AVP", and forwards it uncha= nged. >>> >>> C receives the report, and and entirely stops sending traffic to P. >>> (As far as C knows, P is the server.) >>> >>> This is not the desired behavior. RFC7068 Req 17 says the following. Th= e behavior in this example clearly violates the MUST NOT: >>> >>>> REQ 17: In a mixed environment with nodes that support the solut= ion >>>> and nodes that do not, the solution MUST NOT result in >>>> materially less useful throughput during overload as wou= ld >>>> have resulted if the solution were not present. It SHOU= LD >>>> result in less severe overload in this environment. >>>> >>> If, on the other hand, the OLR internally identified the overloaded nod= e as "S1", C would at least know that it can't do anything useful with the = OLR, since it doesn't know about S1 due to the topology hiding at P. In thi= s case, it just ignores the OLR. That still violates the SHOULD, but at lea= st does not violate the MUST NOT. >>> >>> >>> >>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >>> >>>> Hello, >>>> >>>> I really don't understand the logic for the host to insert its own ide= ntity into the overload report. Wouldn't it be the host to report its own o= verload report in an answer message to the client? Why we need the agent to= do anything in this case? >>>> >>>> To say the least, if the host can insert its identity into the message= , what's the benefit to have the agent for topology hiding? >>>> >>>> Best Regards, >>>> Susan >>>> >>>> -----Original Message----- >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Saturday, August 02, 2014 3:54 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>>> issue #58 Proposal) >>>> >>>> Yes, it could be either. The critical point is that the overloaded ho= st is indicated by the diameter id in the overload report, not the origin-h= ost AVP. >>>> >>>> Steve >>>> >>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>> I don't think you can conflate "host that generated this OLR" with=20 >>>>> "host that is overloaded". It's perfectly valid for them to not be=20 >>>>> the same thing, even for host reports. (But I'd be happy to=20 >>>>> include >>>>> both.) >>>>> >>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>>>> >>>>>> Somewhat on on the path toward generalization, we have a second issu= e currently open that can be solved by having the DOIC node that inserts an= overload report in an answer message include it's own diameter identity in= the overload report. >>>>>> >>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin= -Host. >>>>>> >>>>>> This issue points out that existing non DOIC agents are able to chan= ge the origin-host in answer messages. One example of where this is done i= s in topology hiding implementations. >>>>>> >>>>>> This issue can be addressed through attribution of overload reports. >>>>>> >>>>>> As such, I propose that we add a required AVP to the OC-OLR group AV= P that carries the diameter identity of the DOIC node that inserted the ove= rload report into the answer message. Issue #66 points out the need in hos= t reports and issue #58 points out the need in realm reports. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>> +1 (modulo my comment to generalize) >>>>>>> >>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrot= e: >>>>>>> >>>>>>>> I believe Nirav's view requires all hosts in a realm to be the sam= e vendor and use a proprietary communication protocol to synchronize the ho= st report. Or, if a multiple (redundant or active-active) load-balancing ag= ents are generating the report, they must similarly be synchronized. >>>>>>>> Is seems like including the host name per Ulrich's suggestion = is a simple way of avoiding proprietary mechanisms or coupling between host= s and agents. >>>>>>>> In some applications, the hosts can be completely decoupled (agnos= tic about each other). I think it would be poor to add a synchronization re= quirement just to support DOIC. >>>>>>>> -Dave >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>> lionel.morand@orange.com >>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree=20 >>>>>>>> with Nirav's view. >>>>>>>> Regards, >>>>>>>> Lionel >>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this=20 >>>>>>>> issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. >>>>>>>> In my view, the issue mentioned below - of two agents not 100%= synchronize w.r.t the realm-report - is the related to "how agents synchro= nized between themselves" and since that is not standardized we should not = be developing protocol solution for the case which occurs due to this out-o= f-standards solution. >>>>>>>> Besides, I don't see any issue due to slight miss-synchronizat= ion of the realm-reports between two agents since they should still represe= nt the realm load more or less accurately. >>>>>>>> Also if the agents are not synchronized and if they are playin= g the role of DOIC reacting node then they will apply abatement algorithm b= ased on different values (for the same realm). So it does not matter if the= client does the same. >>>>>>>> Finally, I don't see any value-add of using the "identity=20 >>>>>>>> of the node that sends the realm-report" to discard the other=20 >>>>>>>> report related to the same realm. In other words, this same=20 >>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when=20 >>>>>>>> the overload-report of an realm is active, the client is going=20 >>>>>>>> to ignore all the reports of the same realm which has lower=20 >>>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>>> ignored by the client if their sequence numbers differ. So the=20 >>>>>>>> outcome without including the "identity if the node that sends=20 >>>>>>>> realm report" is same as >>>>>>>>> The effect should be that the reacting node will accept a realm r= eport from anyone when there is no active OLR for the realm but it will onl= y listen to one reporting node when it has an active report. >>>>>>>> Regards, >>>>>>>> Nirav. >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>> Steve Donovan >>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>> >>>>>>>> Issue #58 deals with the fact that there can be multiple senders o= f realm overload report for the same realm. >>>>>>>> >>>>>>>> Ulrich proposes one aspect of what is required in the issue descri= ption: >>>>>>>> >>>>>>>> "In deployments where more than one node is configured to take the= role of a reporting node for realm-routed-request reports, reacting nodes = may receive in different answer messages different realm-routed-request typ= e OLRs inserted by the different reporting nodes. Although it is expected t= hat the different reporting nodes report more or less the same content, it = cannot be expected that reports are 100% synchronized. Especially sequence = numbers may differ. To allow reacting nodes correctly detect outdates/repla= ys/freshness of OLRs in this scenario, it is proposed that realm-routed-req= uest type OLRs are extended to contain the Diameter Identity of the reporti= ng node that inserted the realm-routed-request type OLR. (e.g. as already p= roposed in draft-donovan-dime-agent-overload-01). Reporting nodes that inse= rt realm-routed-request type OLRs to answer messages MUST also insert their= Diameter Identity. Reacting nodes MUST take the Diameter Identity received= within the OLR into account in order to detect outdates/replays/freshness.= " >>>>>>>> >>>>>>>> I agree with Ulrich that realm reports must include the identity o= f the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports as t= he identity of the sender of the host report is implicitly defined by the o= rigin-host in the answer message. >>>>>>>> >>>>>>>> I also agree that the Diameter Identity of the reporting node be u= sed to determine if a received report is ignored or used to update existing= state. To this end I propose that we add wording that for the duration of= a realm report, the reacting node only listens for updates to the realm re= port from from the DOIC node that sent the realm report that resulted in th= e realm OCS being stored. >>>>>>>> >>>>>>>> The effect should be that the reacting node will accept a realm re= port from anyone when there is no active OLR for the realm but it will only= listen to one reporting node when it has an active report. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________________________ >>>>>>>> _ _ _ _______________________________________________________ >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'exp= editeur et le detruire ainsi que les pieces jointes. Les messages electroni= ques etant susceptibles d'alteration, Orange decline toute responsabilite s= i ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>> This message and its attachments may contain confidential=20 >>>>>>>> or privileged information that may be protected by law; they shoul= d 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 h= ave been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> _______________________________________________ >>>> 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 >>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > From nobody Wed Aug 6 11:16:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE21A0417 for ; Wed, 6 Aug 2014 11:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_ACCNT=2.3, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfBKky6V6lj5 for ; Wed, 6 Aug 2014 11:16:17 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4CB1A038A for ; Wed, 6 Aug 2014 11:16:17 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51112 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XF5ky-0004BK-Lt; Wed, 06 Aug 2014 11:16:16 -0700 Message-ID: <53E270ED.4020604@usdonovans.com> Date: Wed, 06 Aug 2014 13:16:13 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Nirav Salot (nsalot)" , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E24837.9080501@usdonovans.com> <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E25DF2.5040606@usdonovans.com> <24059_1407344724_53E26054_24059_1751_1_6B7134B31289DC4FAF731D844122B36E6956E4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <24059_1407344724_53E26054_24059_1751_1_6B7134B31289DC4FAF731D844122B36E6956E4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3_idEIFkP_YlSMji19PNwW2jtxw Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 18:16:20 -0000 Lionel, I understand all of that and that we have separated advertisement of support for a specific application from advertisement of support for DOIC. I thought you were implying that a proxy that advertised support for an application that has incorporated DOIC implied support that it also supported DOIC. Steve On 8/6/14, 12:05 PM, lionel.morand@orange.com wrote: > Hi Steve, > > There are several ways to avoid the problem of backward incompatibilityand changing the application-id is one of them. > In 3GPP, we are using the Supported-Features AVP for the same purpose and the OC-Feature-Vector is introduced in this draft for the same reason i.e. discover what a node is supporting at the application level without changing the application-id. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoyé : mercredi 6 août 2014 18:55 > À : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); dime@ietf.org > Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) > > This is a backwards compatibility scenario. > > The proxy-agent can be 100% compatible with the n-1 version of the application that does not include DOIC support and still advertise support for that application. > > I am not familiar with a mechanism for advertising support for a specific version of the application without changing the application-id itself. Have I missed something? Are you proposing changing the application-idfor all applications that support DOIC? > > Steve > > On 8/6/14, 10:29 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> In that case it would mean that the proxy would not be any more compliant with the application it is supposed to support and advertise in CER/CEA. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mercredi >> 6 août 2014 17:23 À : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); >> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports (was >> Re: DOIC issue #58 Proposal) >> >> Lionel, >> >> No one is saying that an agent cannot be upgraded to support DOIC. >> >> What I did say was that it is not reasonable to expect existing agents, those deployed before DOIC is defined, to be able to support DOIC. >> >> Steve >> >> On 8/6/14, 8:19 AM, lionel.morand@orange.com wrote: >>> Hi, >>> >>> In order to try to conclude on the fact that an agent modifying the Origin-host AVP can only be a proxy agent and then such a proxy can be upgraded to deal with DOIC: >>> >>> >From RFC6733: >>> >>> 6.3. Origin-Host AVP >>> >>> The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity,and >>> it MUST be present in all Diameter messages. This AVP identifies the >>> endpoint that originated the Diameter message. >>> >>> <<< Relay agents MUST NOT modify this AVP. >>> >>> >>> The value of the Origin-Host AVP is guaranteed to be unique within a >>> single host. >>> >>> Note that the Origin-Host AVP may resolve to more than one address as >>> the Diameter peer may support more than one address. >>> >>> This AVP SHOULD be placed as close to the Diameter header as >>> possible. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>> (nsalot) Envoyé : mardi 5 août 2014 19:51 À : Steve Donovan; >>> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports (was >>> Re: DOIC issue #58 Proposal) >>> >>> Steve, >>> >>> What is so difficult here and not sure why two operators are involvedsince the proposal is restricted to change of behavior in either the host or the agent at operator B? >>> Operator B has two choices: >>> - Turn off topology hiding in its agent since agents are not supporting DOIC yet. >>> - Turn off generation of overload report at the host since topology hiding is important. >>> >>> These are configuration related issue and interim/transient problems - until the agents are upgraded to support DOIC. >>> So I don't think we need protocol solution for these types of problems. >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Tuesday, August 05, 2014 5:47 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> How does operator A tell operator B to turn off topology hiding in operator B's network? >>> >>> Keep in mind as well that topology hiding is just one example of a feature that would require an agent to change the origin-host in answer messages. There may be others. We need to solve the general problem and, if possible, solve it through signalling, not configuration. >>> >>> Steve >>> >>> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>>> Exactly what I said :-) >>>> Topology hiding is a non-issue. It is just a matter of configuration. >>>> >>>> Lionel >>>> >>>> Envoyé depuis mon Sony Xperia SP d'Orange >>>> >>>> ---- Nirav Salot (nsalot) a écrit ---- >>>> >>>> >>>> +1 >>>> >>>> Regards, >>>> Nirav. >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>>> (Susan) >>>> Sent: Tuesday, August 05, 2014 8:06 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>> >>>> Hello Ben, >>>> >>>> Putting S1 node in the OLR would break the principle of topology hiding. If this is what the operator could accept, what's the benefit to have the agent on the route to do the topology hiding? >>>> >>>> >From my point of view, there are other ways to solve the problem: >>>> >>>> - If the hosts behind the agent can be enhanced to support overload control, the agent should be enhanced to support overload control, or be enhanced to just discard the OLR AVP. >>>> - Or by configuration disable the topology hiding functionality of the agent since it does not make sense if the S1 could indicate its node identity to the client in the OLR. >>>> - Or by configuration, the hosts behind the agent should know that the agent does not support overload control, then don't send OLR to the client. >>>> >>>> Best Regards, >>>> Susan >>>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Tuesday, August 05, 2014 6:32 AM >>>> To: Shishufeng (Susan) >>>> Cc: Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>> >>>> Let me try to rephrase the problem: >>>> >>>> Consider the following scenario: >>>> >>>> S1 >>>> / >>>> C---P--S2 >>>> \ >>>> S3 >>>> >>>> "P" is a diameter proxy that does _not_ support DOIC, and performs topology hiding. The client and servers do support DOIC. >>>> >>>> Assume S1 becomes overloaded. It sends an host OLR with a reduction percentage of 100% in an answer to a request sent by C. The answer has anOrigin-Host of "S1". >>>> >>>> P receives the answer, and changes Origin-Host to "P". Since P does not support DOIC, it treats the OLR as an "unknown AVP", and forwards it unchanged. >>>> >>>> C receives the report, and and entirely stops sending traffic to P. >>>> (As far as C knows, P is the server.) >>>> >>>> This is not the desired behavior. RFC7068 Req 17 says the following.The behavior in this example clearly violates the MUST NOT: >>>> >>>>> REQ 17: In a mixed environment with nodes that support the solution >>>>> and nodes that do not, the solution MUST NOT result in >>>>> materially less useful throughput during overload aswould >>>>> have resulted if the solution were not present. It SHOULD >>>>> result in less severe overload in this environment. >>>>> >>>> If, on the other hand, the OLR internally identified the overloaded node as "S1", C would at least know that it can't do anything useful withthe OLR, since it doesn't know about S1 due to the topology hiding at P.In this case, it just ignores the OLR. That still violates the SHOULD, but at least does not violate the MUST NOT. >>>> >>>> >>>> >>>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >>>> >>>>> Hello, >>>>> >>>>> I really don't understand the logic for the host to insert its own identity into the overload report. Wouldn't it be the host to report its own overload report in an answer message to the client? Why we need the agent to do anything in this case? >>>>> >>>>> To say the least, if the host can insert its identity into the message, what's the benefit to have the agent for topology hiding? >>>>> >>>>> Best Regards, >>>>> Susan >>>>> >>>>> -----Original Message----- >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: Saturday, August 02, 2014 3:54 AM >>>>> To: Ben Campbell >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>>> issue #58 Proposal) >>>>> >>>>> Yes, it could be either. The critical point is that the overloadedhost is indicated by the diameter id in the overload report, not the origin-host AVP. >>>>> >>>>> Steve >>>>> >>>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>>> I don't think you can conflate "host that generated this OLR" with >>>>>> "host that is overloaded". It's perfectly valid for them to not be >>>>>> the same thing, even for host reports. (But I'd be happy to >>>>>> include >>>>>> both.) >>>>>> >>>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>>>> >>>>>>> Somewhat on on the path toward generalization, we have a second issue currently open that can be solved by having the DOIC node that inserts an overload report in an answer message include it's own diameter identity in the overload report. >>>>>>> >>>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Host. >>>>>>> >>>>>>> This issue points out that existing non DOIC agents are able to change the origin-host in answer messages. One example of where this is done is in topology hiding implementations. >>>>>>> >>>>>>> This issue can be addressed through attribution of overload reports. >>>>>>> >>>>>>> As such, I propose that we add a required AVP to the OC-OLR groupAVP that carries the diameter identity of the DOIC node that inserted the overload report into the answer message. Issue #66 points out the needin host reports and issue #58 points out the need in realm reports. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>>> +1 (modulo my comment to generalize) >>>>>>>> >>>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson wrote: >>>>>>>> >>>>>>>>> I believe Nirav's view requires all hosts in a realm to be the same vendor and use a proprietary communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are generating the report, they must similarly be synchronized. >>>>>>>>> Is seems like including the host name per Ulrich's suggestion is a simple way of avoiding proprietary mechanisms or coupling between hosts and agents. >>>>>>>>> In some applications, the hosts can be completely decoupled (agnostic about each other). I think it would be poor to add a synchronization requirement just to support DOIC. >>>>>>>>> -Dave >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>>>> lionel.morand@orange.com >>>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree >>>>>>>>> with Nirav's view. >>>>>>>>> Regards, >>>>>>>>> Lionel >>>>>>>>> Envoyé depuis mon Sony Xperia SP d'Orange >>>>>>>>> ---- Nirav Salot (nsalot) a écrit ---- Steve, For this >>>>>>>>> issue, I don't agree to include identity of the DOIC node that sends the report, into the realm reports. >>>>>>>>> In my view, the issue mentioned below - of two agents not 100% synchronize w.r.t the realm-report - is the related to "how agents synchronized between themselves" and since that is not standardized we should not be developing protocol solution for the case which occurs due to this out-of-standards solution. >>>>>>>>> Besides, I don't see any issue due to slight miss-synchronization of the realm-reports between two agents since they should still represent the realm load more or less accurately. >>>>>>>>> Also if the agents are not synchronized and if they are playing the role of DOIC reacting node then they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same. >>>>>>>>> Finally, I don't see any value-add of using the "identity >>>>>>>>> of the node that sends the realm-report" to discard the other >>>>>>>>> report related to the same realm. In other words, this same >>>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when >>>>>>>>> the overload-report of an realm is active, the client is going >>>>>>>>> to ignore all the reports of the same realm which has lower >>>>>>>>> sequence number value. So in essence, when two agents are >>>>>>>>> sending realm-reports, one of the reports is automatically >>>>>>>>> ignored by the client if their sequence numbers differ. So the >>>>>>>>> outcome without including the "identity if the node that sends >>>>>>>>> realm report" is same as >>>>>>>>>> The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report. >>>>>>>>> Regards, >>>>>>>>> Nirav. >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>>>> Steve Donovan >>>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>>> To: dime@ietf.org >>>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>>> >>>>>>>>> Issue #58 deals with the fact that there can be multiple senders of realm overload report for the same realm. >>>>>>>>> >>>>>>>>> Ulrich proposes one aspect of what is required in the issue description: >>>>>>>>> >>>>>>>>> "In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detectoutdates/replays/freshness of OLRs in this scenario, it is proposed thatrealm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take theDiameter Identity received within the OLR into acco u nt in order to detect outdates/replays/freshness." >>>>>>>>> >>>>>>>>> I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report. This would be an optional AVP only required for realm reports. It would not be required for host reports as the identity of the sender of the host report is implicitly definedby the origin-host in the answer message. >>>>>>>>> >>>>>>>>> I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state. To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to therealm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored. >>>>>>>>> >>>>>>>>> The effect should be that the reacting node will accept a realmreport from anyone when there is no active OLR for the realm but it willonly listen to one reporting node when it has an active report. >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________________________ >>>>>>>>> _ _ _ _______________________________________________________ >>>>>>>>> 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. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> _______________________________________________ >>>> 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 >>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> 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 notbe 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. >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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 havebeen modified, changed or falsified. >>> Thank you. >>> >>> >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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 anddelete 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. >> >> > > > _________________________________________________________________________________________________________________________ > > 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, deformeou falsifie. Merci. > > This message and its attachments may contain confidential or privilegedinformation 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. > > From nobody Wed Aug 6 13:20:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD51A00E5 for ; Wed, 6 Aug 2014 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYJcFVQeO4Fi for ; Wed, 6 Aug 2014 13:20:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EDE51A00A7 for ; Wed, 6 Aug 2014 13:20:51 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50977 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XF5aU-0001nl-Hu; Wed, 06 Aug 2014 11:05:49 -0700 Message-ID: <53E26E62.8010100@usdonovans.com> Date: Wed, 06 Aug 2014 13:05:22 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" References: <53DA9EA2.4010906@usdonovans.com>, <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <53E246BA.6000202@usdonovans.com> <53E25F67.2090703@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OutGoing-Spam-Status: No, score= 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gbjmGRwWDoN8N5Rm9veCnTlIiZI Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 20:20:54 -0000 Nirav, So you agree there is an issue, correct? If we feel that we have properly characterized the issue, then the next=20 step should be to outline the pros and cons of the possible solutions. I want to make sure we have step one taken care of before we move into=20 step 2. Steve On 8/6/14, 12:25 PM, Nirav Salot (nsalot) wrote: > Steve, > > To be honest, I don't think 1 below - of including identity of the host= in the report - can be considered as solution here since it has multiple= issues: > - It breaks the topology hiding. So basically introduction of new featu= re breaks the existing feature and hence I don't think it is acceptable. > - Finally the client discards the overload report so I am not sure what= good we achieved here as compared to turning off the feature at the sour= ce itself. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 06, 2014 10:31 PM > To: Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue= #58 Proposal) > > Nirav, > All, > > It seems like we at least have agreement that an agent that changes Ori= gin-Host, for whatever reason, can result in clients abating too much tra= ffic routed through that agent. The worst case is that this could result= in 100% of traffic targeted for the Diameter Identity inserted by the ag= ent being throttled. > > We have two solutions proposed: > > 1) A signaling based solution that would allow reacting nodes to know t= hat an "origin-host-munging" agent was in the path of the message. > > 2) An administrative based solution involving turning off "origin-host-= munging" behavior in agents until the agent is upgraded to fully supports= DOIC. > > Is this a correct summary of where we are so far on this issue? > > Steve > > On 8/6/14, 11:14 AM, Nirav Salot (nsalot) wrote: >> Steve, >> >> Thanks for pointing out a different scenario. But for me, nothing chan= ges yet. >> The operator 1 and operator 2 will get in special agreement to share t= he overload report across operator's boundary. As part of the same, (sinc= e the operator 2 does not fully support DOIC yet) the hosts in the operat= or 1 is configured to not include the overload report in the answer messa= ges going towards the operator 2. Or alternatively, the edge agents at op= erator 1 remove those overload reports. >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 06, 2014 8:46 PM >> To: Nirav Salot (nsalot); dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >> issue #58 Proposal) >> >> Nirav, >> >> Here's the cross operator scenario: >> >> Operator 1 Operator 2 >> | >> | +--+ >> | |S1| >> | /+--+ >> | / >> +-+ +-+ | +-+ / +--+ >> |C|-------|A|---|----|A|-----|S2| >> +-+ +-+ | +-+ \ +--+ >> | \ >> | \+--+ >> | |S3| >> | +--+ >> >> >> Operator 1 is fully DOIC capable. >> >> The agent in operator 2's network is not DOIC enabled. >> >> The servers in operator 2's network are DOIC enabled. >> >> All traffic from operator 1 targeted for operator 2 flows through oper= ator 2's agent. >> >> The agent in operator 2's network changes the origin-host header, mayb= e for topology hiding reasons, maybe for other reasons. >> >> C sends a request that is routed to S1. The request includes the OC-S= upported-Features AVP. >> >> S1 is overloaded and sends a response with an overload report requesti= ng a reduction in traffic. In the worst case S1 can send an overload rep= ort with a request for a 100% reduction in traffic. >> >> C will see this as coming from the identity inserted by operator 2's a= gent and, as a result will throttle 100% of traffic targeted for operator= 2's network despite there being two fully operational servers in operato= r 2's network. >> >> While it may be in operator 2's best interest to upgrade their agent t= o support DOIC, operator 1 has no ability to make that upgrade happen. >> >> Steve >> >> >> On 8/5/14, 12:51 PM, Nirav Salot (nsalot) wrote: >>> Steve, >>> >>> What is so difficult here and not sure why two operators are involved= since the proposal is restricted to change of behavior in either the hos= t or the agent at operator B? >>> Operator B has two choices: >>> - Turn off topology hiding in its agent since agents are not supporti= ng DOIC yet. >>> - Turn off generation of overload report at the host since topology h= iding is important. >>> >>> These are configuration related issue and interim/transient problems = - until the agents are upgraded to support DOIC. >>> So I don't think we need protocol solution for these types of problem= s. >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Tuesday, August 05, 2014 5:47 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>> >>> How does operator A tell operator B to turn off topology hiding in op= erator B's network? >>> >>> Keep in mind as well that topology hiding is just one example of a fe= ature that would require an agent to change the origin-host in answer mes= sages. There may be others. We need to solve the general problem and, i= f possible, solve it through signalling, not configuration. >>> >>> Steve >>> >>> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>>> Exactly what I said :-) >>>> Topology hiding is a non-issue. It is just a matter of configuration= =2E >>>> >>>> Lionel >>>> >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>> >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>> >>>> >>>> +1 >>>> >>>> Regards, >>>> Nirav. >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>>> (Susan) >>>> Sent: Tuesday, August 05, 2014 8:06 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>> >>>> Hello Ben, >>>> >>>> Putting S1 node in the OLR would break the principle of topology hid= ing. If this is what the operator could accept, what's the benefit to hav= e the agent on the route to do the topology hiding? >>>> >>>> >From my point of view, there are other ways to solve the problem: >>>> >>>> - If the hosts behind the agent can be enhanced to support overload = control, the agent should be enhanced to support overload control, or be = enhanced to just discard the OLR AVP. >>>> - Or by configuration disable the topology hiding functionality of t= he agent since it does not make sense if the S1 could indicate its node i= dentity to the client in the OLR. >>>> - Or by configuration, the hosts behind the agent should know that t= he agent does not support overload control, then don't send OLR to the cl= ient. >>>> >>>> Best Regards, >>>> Susan >>>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Tuesday, August 05, 2014 6:32 AM >>>> To: Shishufeng (Susan) >>>> Cc: Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>> >>>> Let me try to rephrase the problem: >>>> >>>> Consider the following scenario: >>>> >>>> S1 >>>> / >>>> C---P--S2 >>>> \ >>>> S3 >>>> >>>> "P" is a diameter proxy that does _not_ support DOIC, and performs t= opology hiding. The client and servers do support DOIC. >>>> >>>> Assume S1 becomes overloaded. It sends an host OLR with a reduction = percentage of 100% in an answer to a request sent by C. The answer has an= Origin-Host of "S1". >>>> >>>> P receives the answer, and changes Origin-Host to "P". Since P does = not support DOIC, it treats the OLR as an "unknown AVP", and forwards it = unchanged. >>>> >>>> C receives the report, and and entirely stops sending traffic to P. >>>> (As far as C knows, P is the server.) >>>> >>>> This is not the desired behavior. RFC7068 Req 17 says the following.= The behavior in this example clearly violates the MUST NOT: >>>> >>>>> REQ 17: In a mixed environment with nodes that support the s= olution >>>>> and nodes that do not, the solution MUST NOT result = in >>>>> materially less useful throughput during overload as= would >>>>> have resulted if the solution were not present. It = SHOULD >>>>> result in less severe overload in this environment. >>>>> >>>> If, on the other hand, the OLR internally identified the overloaded = node as "S1", C would at least know that it can't do anything useful with= the OLR, since it doesn't know about S1 due to the topology hiding at P.= In this case, it just ignores the OLR. That still violates the SHOULD, b= ut at least does not violate the MUST NOT. >>>> >>>> >>>> >>>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) wrote: >>>> >>>>> Hello, >>>>> >>>>> I really don't understand the logic for the host to insert its own = identity into the overload report. Wouldn't it be the host to report its = own overload report in an answer message to the client? Why we need the a= gent to do anything in this case? >>>>> >>>>> To say the least, if the host can insert its identity into the mess= age, what's the benefit to have the agent for topology hiding? >>>>> >>>>> Best Regards, >>>>> Susan >>>>> >>>>> -----Original Message----- >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: Saturday, August 02, 2014 3:54 AM >>>>> To: Ben Campbell >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>>> issue #58 Proposal) >>>>> >>>>> Yes, it could be either. The critical point is that the overloaded= host is indicated by the diameter id in the overload report, not the ori= gin-host AVP. >>>>> >>>>> Steve >>>>> >>>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>>> I don't think you can conflate "host that generated this OLR" with= >>>>>> "host that is overloaded". It's perfectly valid for them to not be= >>>>>> the same thing, even for host reports. (But I'd be happy to >>>>>> include >>>>>> both.) >>>>>> >>>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan wrote: >>>>>> >>>>>>> Somewhat on on the path toward generalization, we have a second i= ssue currently open that can be solved by having the DOIC node that inser= ts an overload report in an answer message include it's own diameter iden= tity in the overload report. >>>>>>> >>>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an Ori= gin-Host. >>>>>>> >>>>>>> This issue points out that existing non DOIC agents are able to c= hange the origin-host in answer messages. One example of where this is d= one is in topology hiding implementations. >>>>>>> >>>>>>> This issue can be addressed through attribution of overload repor= ts. >>>>>>> >>>>>>> As such, I propose that we add a required AVP to the OC-OLR group= AVP that carries the diameter identity of the DOIC node that inserted th= e overload report into the answer message. Issue #66 points out the need= in host reports and issue #58 points out the need in realm reports. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>>> +1 (modulo my comment to generalize) >>>>>>>> >>>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson w= rote: >>>>>>>> >>>>>>>>> I believe Nirav's view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize t= he host report. Or, if a multiple (redundant or active-active) load-balan= cing agents are generating the report, they must similarly be synchronize= d. >>>>>>>>> Is seems like including the host name per Ulrich's suggest= ion is a simple way of avoiding proprietary mechanisms or coupling betwee= n hosts and agents. >>>>>>>>> In some applications, the hosts can be completely decoupled (ag= nostic about each other). I think it would be poor to add a synchronizati= on requirement just to support DOIC. >>>>>>>>> -Dave >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of= >>>>>>>>> lionel.morand@orange.com >>>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I agree= >>>>>>>>> with Nirav's view. >>>>>>>>> Regards, >>>>>>>>> Lionel >>>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this= >>>>>>>>> issue, I don't agree to include identity of the DOIC node that = sends the report, into the realm reports. >>>>>>>>> In my view, the issue mentioned below - of two agents not = 100% synchronize w.r.t the realm-report - is the related to "how agents s= ynchronized between themselves" and since that is not standardized we sho= uld not be developing protocol solution for the case which occurs due to = this out-of-standards solution. >>>>>>>>> Besides, I don't see any issue due to slight miss-synchron= ization of the realm-reports between two agents since they should still r= epresent the realm load more or less accurately. >>>>>>>>> Also if the agents are not synchronized and if they are pl= aying the role of DOIC reacting node then they will apply abatement algor= ithm based on different values (for the same realm). So it does not matte= r if the client does the same. >>>>>>>>> Finally, I don't see any value-add of using the "identity >>>>>>>>> of the node that sends the realm-report" to discard the other >>>>>>>>> report related to the same realm. In other words, this same >>>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when= >>>>>>>>> the overload-report of an realm is active, the client is going >>>>>>>>> to ignore all the reports of the same realm which has lower >>>>>>>>> sequence number value. So in essence, when two agents are >>>>>>>>> sending realm-reports, one of the reports is automatically >>>>>>>>> ignored by the client if their sequence numbers differ. So the >>>>>>>>> outcome without including the "identity if the node that sends >>>>>>>>> realm report" is same as >>>>>>>>>> The effect should be that the reacting node will accept a real= m report from anyone when there is no active OLR for the realm but it wil= l only listen to one reporting node when it has an active report. >>>>>>>>> Regards, >>>>>>>>> Nirav. >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>>>> Steve Donovan >>>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>>> To: dime@ietf.org >>>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>>> >>>>>>>>> Issue #58 deals with the fact that there can be multiple sender= s of realm overload report for the same realm. >>>>>>>>> >>>>>>>>> Ulrich proposes one aspect of what is required in the issue des= cription: >>>>>>>>> >>>>>>>>> "In deployments where more than one node is configured to take = the role of a reporting node for realm-routed-request reports, reacting n= odes may receive in different answer messages different realm-routed-requ= est type OLRs inserted by the different reporting nodes. Although it is e= xpected that the different reporting nodes report more or less the same c= ontent, it cannot be expected that reports are 100% synchronized. Especia= lly sequence numbers may differ. To allow reacting nodes correctly detect= outdates/replays/freshness of OLRs in this scenario, it is proposed that= realm-routed-request type OLRs are extended to contain the Diameter Iden= tity of the reporting node that inserted the realm-routed-request type OL= R. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Re= porting nodes that insert realm-routed-request type OLRs to answer messag= es MUST also insert their Diameter Identity. Reacting nodes MUST take the= Diameter Identity received within the OLR into account in order to detec= t outdates/replays/freshness." >>>>>>>>> >>>>>>>>> I agree with Ulrich that realm reports must include the identit= y of the DOIC node that sends the report. This would be an optional AVP = only required for realm reports. It would not be required for host repor= ts as the identity of the sender of the host report is implicitly defined= by the origin-host in the answer message. >>>>>>>>> >>>>>>>>> I also agree that the Diameter Identity of the reporting node b= e used to determine if a received report is ignored or used to update exi= sting state. To this end I propose that we add wording that for the dura= tion of a realm report, the reacting node only listens for updates to the= realm report from from the DOIC node that sent the realm report that res= ulted in the realm OCS being stored. >>>>>>>>> >>>>>>>>> The effect should be that the reacting node will accept a realm= report from anyone when there is no active OLR for the realm but it will= only listen to one reporting node when it has an active report. >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________________________= >>>>>>>>> _ _ _ _______________________________________________________ >>>>>>>>> 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 elec= troniques etant susceptibles d'alteration, Orange decline toute responsab= ilite 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 sh= ould not be distributed, used or copied without authorisation. >>>>>>>>> If you have received this email in error, please notify the sen= der and delete this message and its attachments. >>>>>>>>> As emails may be altered, Orange is not liable for messages tha= t have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>> _______________________________________________ >>>>>>>>> DiME mailing list >>>>>>>>> DiME@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> 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 >>>> >>>> ____________________________________________________________________= >>>> _ _ ___________________________________________________ >>>> >>>> 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 det= ruire ainsi que les pieces jointes. Les messages electroniques etant susc= eptibles 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 a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> > > From nobody Thu Aug 7 11:41:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82E41A037D for ; Thu, 7 Aug 2014 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_2m1gvbiVPm for ; Thu, 7 Aug 2014 11:41:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4684D1A0005 for ; Thu, 7 Aug 2014 11:41:09 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77If4Mp051354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:41:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53E25F67.2090703@usdonovans.com> Date: Thu, 7 Aug 2014 13:41:04 -0500 X-Mao-Original-Outgoing-Id: 429129664.186026-f3956f4bba4d2102af5c3a3f75bebf70 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <53E246BA.6000202@usdonovans.com> <53E25F67.2090703@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3OE9tRpnxCziTo69dMY0x_XXBKM Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:41:12 -0000 On Aug 6, 2014, at 12:01 PM, Steve Donovan = wrote: > Nirav, > All, >=20 > It seems like we at least have agreement that an agent that changes = Origin-Host, for whatever reason, can result in clients abating too much = traffic routed through that agent. The worst case is that this could = result in 100% of traffic targeted for the Diameter Identity inserted by = the agent being throttled. >=20 > We have two solutions proposed: >=20 > 1) A signaling based solution that would allow reacting nodes to know = that an "origin-host-munging" agent was in the path of the message. I would say "allows the reacting node to do the right thing even if an = OHM agent is in the path, at the expense of potentially leaking topology = information to the reacting node." >=20 > 2) An administrative based solution involving turning off = "origin-host-munging" behavior in agents until the agent is upgraded to = fully supports DOIC. >=20 > Is this a correct summary of where we are so far on this issue? >=20 I think we have also mentioned a third option: Configure DOIC = supporting nodes to not send OLRs across, or accept OLRs from = non-supporting OHM agents. (Preferably with some mechanism to actually = _detect_ non-supporting agents rather than requiring configuration on a = per-agent basis. ) From nobody Thu Aug 7 11:52:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED331A0359 for ; Thu, 7 Aug 2014 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ2CQ2yJ3JjZ for ; Thu, 7 Aug 2014 11:52:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BDC1A0196 for ; Thu, 7 Aug 2014 11:52:28 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77IqMhA052196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:52:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Thu, 7 Aug 2014 13:52:22 -0500 X-Mao-Original-Outgoing-Id: 429130342.770009-cfe4094866185390882be4f861c458e8 Content-Transfer-Encoding: quoted-printable Message-Id: <2D1AD352-37B4-44DC-B68F-9381278BED18@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <53E246BA.6000202@usdonovans.com> <53E25F67.2090703@usdonovans.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CubJph7SGaSStK94TkWuM5JRSKQ Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:52:33 -0000 On Aug 6, 2014, at 12:25 PM, Nirav Salot (nsalot) = wrote: > Steve, >=20 > To be honest, I don't think 1 below - of including identity of the = host in the report - can be considered as solution here since it has = multiple issues: > - It breaks the topology hiding. So basically introduction of new = feature breaks the existing feature and hence I don't think it is = acceptable.=20 It's a cost. We should discuss more explicitly whether it's a reasonable = cost. > - Finally the client discards the overload report so I am not sure = what good we achieved here as compared to turning off the feature at the = source itself. >=20 Discarding the report is _much_ better than acting incorrectly on a = report. Req 17 says the "solution MUST not result in materially less = useful throughput" than if DOIC was not deployed.=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 > Sent: Wednesday, August 06, 2014 10:31 PM > To: Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC = issue #58 Proposal) >=20 > Nirav, > All, >=20 > It seems like we at least have agreement that an agent that changes = Origin-Host, for whatever reason, can result in clients abating too much = traffic routed through that agent. The worst case is that this could = result in 100% of traffic targeted for the Diameter Identity inserted by = the agent being throttled. >=20 > We have two solutions proposed: >=20 > 1) A signaling based solution that would allow reacting nodes to know = that an "origin-host-munging" agent was in the path of the message. >=20 > 2) An administrative based solution involving turning off = "origin-host-munging" behavior in agents until the agent is upgraded to = fully supports DOIC. >=20 > Is this a correct summary of where we are so far on this issue? >=20 > Steve >=20 > On 8/6/14, 11:14 AM, Nirav Salot (nsalot) wrote: >> Steve, >>=20 >> Thanks for pointing out a different scenario. But for me, nothing = changes yet. >> The operator 1 and operator 2 will get in special agreement to share = the overload report across operator's boundary. As part of the same, = (since the operator 2 does not fully support DOIC yet) the hosts in the = operator 1 is configured to not include the overload report in the = answer messages going towards the operator 2. Or alternatively, the edge = agents at operator 1 remove those overload reports. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 06, 2014 8:46 PM >> To: Nirav Salot (nsalot); dime@ietf.org >> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >> issue #58 Proposal) >>=20 >> Nirav, >>=20 >> Here's the cross operator scenario: >>=20 >> Operator 1 Operator 2 >> | >> | +--+ >> | |S1| >> | /+--+ >> | / >> +-+ +-+ | +-+ / +--+ >> |C|-------|A|---|----|A|-----|S2| >> +-+ +-+ | +-+ \ +--+ >> | \ >> | \+--+ >> | |S3| >> | +--+ >>=20 >>=20 >> Operator 1 is fully DOIC capable. >>=20 >> The agent in operator 2's network is not DOIC enabled. >>=20 >> The servers in operator 2's network are DOIC enabled. >>=20 >> All traffic from operator 1 targeted for operator 2 flows through = operator 2's agent. >>=20 >> The agent in operator 2's network changes the origin-host header, = maybe for topology hiding reasons, maybe for other reasons. >>=20 >> C sends a request that is routed to S1. The request includes the = OC-Supported-Features AVP. >>=20 >> S1 is overloaded and sends a response with an overload report = requesting a reduction in traffic. In the worst case S1 can send an = overload report with a request for a 100% reduction in traffic. >>=20 >> C will see this as coming from the identity inserted by operator 2's = agent and, as a result will throttle 100% of traffic targeted for = operator 2's network despite there being two fully operational servers = in operator 2's network. >>=20 >> While it may be in operator 2's best interest to upgrade their agent = to support DOIC, operator 1 has no ability to make that upgrade happen. >>=20 >> Steve >>=20 >>=20 >> On 8/5/14, 12:51 PM, Nirav Salot (nsalot) wrote: >>> Steve, >>>=20 >>> What is so difficult here and not sure why two operators are = involved since the proposal is restricted to change of behavior in = either the host or the agent at operator B? >>> Operator B has two choices: >>> - Turn off topology hiding in its agent since agents are not = supporting DOIC yet. >>> - Turn off generation of overload report at the host since topology = hiding is important. >>>=20 >>> These are configuration related issue and interim/transient problems = - until the agents are upgraded to support DOIC. >>> So I don't think we need protocol solution for these types of = problems. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Tuesday, August 05, 2014 5:47 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20 >>> issue #58 Proposal) >>>=20 >>> How does operator A tell operator B to turn off topology hiding in = operator B's network? >>>=20 >>> Keep in mind as well that topology hiding is just one example of a = feature that would require an agent to change the origin-host in answer = messages. There may be others. We need to solve the general problem = and, if possible, solve it through signalling, not configuration. >>>=20 >>> Steve >>>=20 >>> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>>> Exactly what I said :-) >>>> Topology hiding is a non-issue. It is just a matter of = configuration. >>>>=20 >>>> Lionel >>>>=20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>=20 >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>=20 >>>>=20 >>>> +1 >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>>> (Susan) >>>> Sent: Tuesday, August 05, 2014 8:06 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20= >>>> issue #58 Proposal) >>>>=20 >>>> Hello Ben, >>>>=20 >>>> Putting S1 node in the OLR would break the principle of topology = hiding. If this is what the operator could accept, what's the benefit to = have the agent on the route to do the topology hiding? >>>>=20 >>>>> =46rom my point of view, there are other ways to solve the = problem: >>>>=20 >>>> - If the hosts behind the agent can be enhanced to support overload = control, the agent should be enhanced to support overload control, or be = enhanced to just discard the OLR AVP. >>>> - Or by configuration disable the topology hiding functionality of = the agent since it does not make sense if the S1 could indicate its node = identity to the client in the OLR. >>>> - Or by configuration, the hosts behind the agent should know that = the agent does not support overload control, then don't send OLR to the = client. >>>>=20 >>>> Best Regards, >>>> Susan >>>>=20 >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Tuesday, August 05, 2014 6:32 AM >>>> To: Shishufeng (Susan) >>>> Cc: Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20= >>>> issue #58 Proposal) >>>>=20 >>>> Let me try to rephrase the problem: >>>>=20 >>>> Consider the following scenario: >>>>=20 >>>> S1 >>>> / >>>> C---P--S2 >>>> \ >>>> S3 >>>>=20 >>>> "P" is a diameter proxy that does _not_ support DOIC, and performs = topology hiding. The client and servers do support DOIC. >>>>=20 >>>> Assume S1 becomes overloaded. It sends an host OLR with a reduction = percentage of 100% in an answer to a request sent by C. The answer has = an Origin-Host of "S1". >>>>=20 >>>> P receives the answer, and changes Origin-Host to "P". Since P does = not support DOIC, it treats the OLR as an "unknown AVP", and forwards it = unchanged. >>>>=20 >>>> C receives the report, and and entirely stops sending traffic to P. >>>> (As far as C knows, P is the server.) >>>>=20 >>>> This is not the desired behavior. RFC7068 Req 17 says the = following. The behavior in this example clearly violates the MUST NOT: >>>>=20 >>>>> REQ 17: In a mixed environment with nodes that support the = solution >>>>> and nodes that do not, the solution MUST NOT result = in >>>>> materially less useful throughput during overload as = would >>>>> have resulted if the solution were not present. It = SHOULD >>>>> result in less severe overload in this environment. >>>>>=20 >>>> If, on the other hand, the OLR internally identified the overloaded = node as "S1", C would at least know that it can't do anything useful = with the OLR, since it doesn't know about S1 due to the topology hiding = at P. In this case, it just ignores the OLR. That still violates the = SHOULD, but at least does not violate the MUST NOT. >>>>=20 >>>>=20 >>>>=20 >>>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) = wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I really don't understand the logic for the host to insert its own = identity into the overload report. Wouldn't it be the host to report its = own overload report in an answer message to the client? Why we need the = agent to do anything in this case? >>>>>=20 >>>>> To say the least, if the host can insert its identity into the = message, what's the benefit to have the agent for topology hiding? >>>>>=20 >>>>> Best Regards, >>>>> Susan >>>>>=20 >>>>> -----Original Message----- >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: Saturday, August 02, 2014 3:54 AM >>>>> To: Ben Campbell >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC=20= >>>>> issue #58 Proposal) >>>>>=20 >>>>> Yes, it could be either. The critical point is that the = overloaded host is indicated by the diameter id in the overload report, = not the origin-host AVP. >>>>>=20 >>>>> Steve >>>>>=20 >>>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>>> I don't think you can conflate "host that generated this OLR" = with=20 >>>>>> "host that is overloaded". It's perfectly valid for them to not = be=20 >>>>>> the same thing, even for host reports. (But I'd be happy to=20 >>>>>> include >>>>>> both.) >>>>>>=20 >>>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>>>>>=20 >>>>>>> Somewhat on on the path toward generalization, we have a second = issue currently open that can be solved by having the DOIC node that = inserts an overload report in an answer message include it's own = diameter identity in the overload report. >>>>>>>=20 >>>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >>>>>>>=20 >>>>>>> This issue points out that existing non DOIC agents are able to = change the origin-host in answer messages. One example of where this is = done is in topology hiding implementations. >>>>>>>=20 >>>>>>> This issue can be addressed through attribution of overload = reports. >>>>>>>=20 >>>>>>> As such, I propose that we add a required AVP to the OC-OLR = group AVP that carries the diameter identity of the DOIC node that = inserted the overload report into the answer message. Issue #66 points = out the need in host reports and issue #58 points out the need in realm = reports. >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>>=20 >>>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>>> +1 (modulo my comment to generalize) >>>>>>>>=20 >>>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson = wrote: >>>>>>>>=20 >>>>>>>>> I believe Nirav's view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>>>>>>>> Is seems like including the host name per Ulrich's = suggestion is a simple way of avoiding proprietary mechanisms or = coupling between hosts and agents. >>>>>>>>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>>>>>>>> -Dave >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20= >>>>>>>>> lionel.morand@orange.com >>>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I = agree=20 >>>>>>>>> with Nirav's view. >>>>>>>>> Regards, >>>>>>>>> Lionel >>>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this=20= >>>>>>>>> issue, I don't agree to include identity of the DOIC node that = sends the report, into the realm reports. >>>>>>>>> In my view, the issue mentioned below - of two agents not = 100% synchronize w.r.t the realm-report - is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>>>>>>>> Besides, I don't see any issue due to slight = miss-synchronization of the realm-reports between two agents since they = should still represent the realm load more or less accurately. >>>>>>>>> Also if the agents are not synchronized and if they are = playing the role of DOIC reacting node then they will apply abatement = algorithm based on different values (for the same realm). So it does not = matter if the client does the same. >>>>>>>>> Finally, I don't see any value-add of using the "identity=20= >>>>>>>>> of the node that sends the realm-report" to discard the other=20= >>>>>>>>> report related to the same realm. In other words, this same=20 >>>>>>>>> logic can be achieved using sequence-numbers as well, i.e. = when=20 >>>>>>>>> the overload-report of an realm is active, the client is going=20= >>>>>>>>> to ignore all the reports of the same realm which has lower=20 >>>>>>>>> sequence number value. So in essence, when two agents are=20 >>>>>>>>> sending realm-reports, one of the reports is automatically=20 >>>>>>>>> ignored by the client if their sequence numbers differ. So the=20= >>>>>>>>> outcome without including the "identity if the node that sends=20= >>>>>>>>> realm report" is same as >>>>>>>>>> The effect should be that the reacting node will accept a = realm report from anyone when there is no active OLR for the realm but = it will only listen to one reporting node when it has an active report. >>>>>>>>> Regards, >>>>>>>>> Nirav. >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >>>>>>>>> Steve Donovan >>>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>>> To: dime@ietf.org >>>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>>>=20 >>>>>>>>> Issue #58 deals with the fact that there can be multiple = senders of realm overload report for the same realm. >>>>>>>>>=20 >>>>>>>>> Ulrich proposes one aspect of what is required in the issue = description: >>>>>>>>>=20 >>>>>>>>> "In deployments where more than one node is configured to take = the role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>>>>=20 >>>>>>>>> I agree with Ulrich that realm reports must include the = identity of the DOIC node that sends the report. This would be an = optional AVP only required for realm reports. It would not be required = for host reports as the identity of the sender of the host report is = implicitly defined by the origin-host in the answer message. >>>>>>>>>=20 >>>>>>>>> I also agree that the Diameter Identity of the reporting node = be used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>>>>>>>=20 >>>>>>>>> The effect should be that the reacting node will accept a = realm report from anyone when there is no active OLR for the realm but = it will only listen to one reporting node when it has an active report. >>>>>>>>>=20 >>>>>>>>> Steve >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> = _______________________________________________________________ >>>>>>>>> _ _ _ _______________________________________________________ >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>>> informations confidentielles ou privilegiees et ne doivent = donc=20 >>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20= >>>>>>>>> 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=20= >>>>>>>>> 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. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> _______________________________________________ >>>> 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 >>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20= >>>> 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. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> 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. >>>>=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 >>=20 >>=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Aug 7 11:53:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EC61A035E for ; Thu, 7 Aug 2014 11:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXnYbkxQJQgC for ; Thu, 7 Aug 2014 11:53:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96861A0331 for ; Thu, 7 Aug 2014 11:53:01 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77IqMhB052196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:52:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53E25DF2.5040606@usdonovans.com> Date: Thu, 7 Aug 2014 13:52:58 -0500 X-Mao-Original-Outgoing-Id: 429130378.63077-addfefe0f14f6dfd9017b69a7ac17e83 Content-Transfer-Encoding: quoted-printable Message-Id: <3BA990BD-97EB-40DF-81EB-55BF67F1123A@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E24837.9080501@usdonovans.com> <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E25DF2.5040606@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/r-m_52DN515VbplRVjNUeodJLdk Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:53:10 -0000 On Aug 6, 2014, at 11:55 AM, Steve Donovan = wrote: > This is a backwards compatibility scenario. >=20 > The proxy-agent can be 100% compatible with the n-1 version of the = application that does not include DOIC support and still advertise = support for that application. >=20 > I am not familiar with a mechanism for advertising support for a = specific version of the application without changing the application-id = itself. Have I missed something? Are you proposing changing the = application-id for all applications that support DOIC? That is _explicitly_ not supported. (That is, 6733 goes out of its way = to say there is no versioning of applications.) >=20 > Steve >=20 > On 8/6/14, 10:29 AM, lionel.morand@orange.com wrote: >> Hi Steve, >>=20 >> In that case it would mean that the proxy would not be any more = compliant with the application it is supposed to support and advertise = in CER/CEA. >>=20 >> Regards, >>=20 >> Lionel >>=20 >>=20 >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] >> Envoy=E9 : mercredi 6 ao=FBt 2014 17:23 >> =C0 : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); dime@ietf.org >> Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC = issue #58 Proposal) >>=20 >> Lionel, >>=20 >> No one is saying that an agent cannot be upgraded to support DOIC. >>=20 >> What I did say was that it is not reasonable to expect existing = agents, those deployed before DOIC is defined, to be able to support = DOIC. >>=20 >> Steve >>=20 >> On 8/6/14, 8:19 AM, lionel.morand@orange.com wrote: >>> Hi, >>>=20 >>> In order to try to conclude on the fact that an agent modifying the = Origin-host AVP can only be a proxy agent and then such a proxy can be = upgraded to deal with DOIC: >>>=20 >>> >=46rom RFC6733: >>>=20 >>> 6.3. Origin-Host AVP >>>=20 >>> The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, = and >>> it MUST be present in all Diameter messages. This AVP = identifies the >>> endpoint that originated the Diameter message. >>>=20 >>> <<< Relay agents MUST NOT modify this AVP. >>> >>>=20 >>> The value of the Origin-Host AVP is guaranteed to be unique = within a >>> single host. >>>=20 >>> Note that the Origin-Host AVP may resolve to more than one = address as >>> the Diameter peer may support more than one address. >>>=20 >>> This AVP SHOULD be placed as close to the Diameter header as >>> possible. >>>=20 >>> Regards, >>>=20 >>> Lionel >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>> (nsalot) Envoy=E9 : mardi 5 ao=FBt 2014 19:51 =C0 : Steve Donovan; >>> dime@ietf.org Objet : Re: [Dime] Attribution of Overload Reports = (was >>> Re: DOIC issue #58 Proposal) >>>=20 >>> Steve, >>>=20 >>> What is so difficult here and not sure why two operators are = involved since the proposal is restricted to change of behavior in = either the host or the agent at operator B? >>> Operator B has two choices: >>> - Turn off topology hiding in its agent since agents are not = supporting DOIC yet. >>> - Turn off generation of overload report at the host since topology = hiding is important. >>>=20 >>> These are configuration related issue and interim/transient problems = - until the agents are upgraded to support DOIC. >>> So I don't think we need protocol solution for these types of = problems. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Tuesday, August 05, 2014 5:47 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>> issue #58 Proposal) >>>=20 >>> How does operator A tell operator B to turn off topology hiding in = operator B's network? >>>=20 >>> Keep in mind as well that topology hiding is just one example of a = feature that would require an agent to change the origin-host in answer = messages. There may be others. We need to solve the general problem = and, if possible, solve it through signalling, not configuration. >>>=20 >>> Steve >>>=20 >>> On 8/5/14, 2:22 AM, lionel.morand@orange.com wrote: >>>> Exactly what I said :-) >>>> Topology hiding is a non-issue. It is just a matter of = configuration. >>>>=20 >>>> Lionel >>>>=20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>=20 >>>> ---- Nirav Salot (nsalot) a =E9crit ---- >>>>=20 >>>>=20 >>>> +1 >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng >>>> (Susan) >>>> Sent: Tuesday, August 05, 2014 8:06 AM >>>> To: Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>>=20 >>>> Hello Ben, >>>>=20 >>>> Putting S1 node in the OLR would break the principle of topology = hiding. If this is what the operator could accept, what's the benefit to = have the agent on the route to do the topology hiding? >>>>=20 >>>> >=46rom my point of view, there are other ways to solve the = problem: >>>>=20 >>>> - If the hosts behind the agent can be enhanced to support overload = control, the agent should be enhanced to support overload control, or be = enhanced to just discard the OLR AVP. >>>> - Or by configuration disable the topology hiding functionality of = the agent since it does not make sense if the S1 could indicate its node = identity to the client in the OLR. >>>> - Or by configuration, the hosts behind the agent should know that = the agent does not support overload control, then don't send OLR to the = client. >>>>=20 >>>> Best Regards, >>>> Susan >>>>=20 >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Tuesday, August 05, 2014 6:32 AM >>>> To: Shishufeng (Susan) >>>> Cc: Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>> issue #58 Proposal) >>>>=20 >>>> Let me try to rephrase the problem: >>>>=20 >>>> Consider the following scenario: >>>>=20 >>>> S1 >>>> / >>>> C---P--S2 >>>> \ >>>> S3 >>>>=20 >>>> "P" is a diameter proxy that does _not_ support DOIC, and performs = topology hiding. The client and servers do support DOIC. >>>>=20 >>>> Assume S1 becomes overloaded. It sends an host OLR with a reduction = percentage of 100% in an answer to a request sent by C. The answer has = an Origin-Host of "S1". >>>>=20 >>>> P receives the answer, and changes Origin-Host to "P". Since P does = not support DOIC, it treats the OLR as an "unknown AVP", and forwards it = unchanged. >>>>=20 >>>> C receives the report, and and entirely stops sending traffic to P. >>>> (As far as C knows, P is the server.) >>>>=20 >>>> This is not the desired behavior. RFC7068 Req 17 says the = following. The behavior in this example clearly violates the MUST NOT: >>>>=20 >>>>> REQ 17: In a mixed environment with nodes that support the = solution >>>>> and nodes that do not, the solution MUST NOT result = in >>>>> materially less useful throughput during overload as = would >>>>> have resulted if the solution were not present. It = SHOULD >>>>> result in less severe overload in this environment. >>>>>=20 >>>> If, on the other hand, the OLR internally identified the overloaded = node as "S1", C would at least know that it can't do anything useful = with the OLR, since it doesn't know about S1 due to the topology hiding = at P. In this case, it just ignores the OLR. That still violates the = SHOULD, but at least does not violate the MUST NOT. >>>>=20 >>>>=20 >>>>=20 >>>> On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) = wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I really don't understand the logic for the host to insert its own = identity into the overload report. Wouldn't it be the host to report its = own overload report in an answer message to the client? Why we need the = agent to do anything in this case? >>>>>=20 >>>>> To say the least, if the host can insert its identity into the = message, what's the benefit to have the agent for topology hiding? >>>>>=20 >>>>> Best Regards, >>>>> Susan >>>>>=20 >>>>> -----Original Message----- >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: Saturday, August 02, 2014 3:54 AM >>>>> To: Ben Campbell >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC >>>>> issue #58 Proposal) >>>>>=20 >>>>> Yes, it could be either. The critical point is that the = overloaded host is indicated by the diameter id in the overload report, = not the origin-host AVP. >>>>>=20 >>>>> Steve >>>>>=20 >>>>> On 8/1/14, 2:02 PM, Ben Campbell wrote: >>>>>> I don't think you can conflate "host that generated this OLR" = with >>>>>> "host that is overloaded". It's perfectly valid for them to not = be >>>>>> the same thing, even for host reports. (But I'd be happy to >>>>>> include >>>>>> both.) >>>>>>=20 >>>>>> On Aug 1, 2014, at 11:09 AM, Steve Donovan = wrote: >>>>>>=20 >>>>>>> Somewhat on on the path toward generalization, we have a second = issue currently open that can be solved by having the DOIC node that = inserts an overload report in an answer message include it's own = diameter identity in the overload report. >>>>>>>=20 >>>>>>> I'm referring to issue #66 - Non-Supporting Agent Changing an = Origin-Host. >>>>>>>=20 >>>>>>> This issue points out that existing non DOIC agents are able to = change the origin-host in answer messages. One example of where this is = done is in topology hiding implementations. >>>>>>>=20 >>>>>>> This issue can be addressed through attribution of overload = reports. >>>>>>>=20 >>>>>>> As such, I propose that we add a required AVP to the OC-OLR = group AVP that carries the diameter identity of the DOIC node that = inserted the overload report into the answer message. Issue #66 points = out the need in host reports and issue #58 points out the need in realm = reports. >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>>=20 >>>>>>> On 8/1/14, 9:54 AM, Ben Campbell wrote: >>>>>>>> +1 (modulo my comment to generalize) >>>>>>>>=20 >>>>>>>> On Aug 1, 2014, at 9:49 AM, Dave Dolson = wrote: >>>>>>>>=20 >>>>>>>>> I believe Nirav's view requires all hosts in a realm to be the = same vendor and use a proprietary communication protocol to synchronize = the host report. Or, if a multiple (redundant or active-active) = load-balancing agents are generating the report, they must similarly be = synchronized. >>>>>>>>> Is seems like including the host name per Ulrich's = suggestion is a simple way of avoiding proprietary mechanisms or = coupling between hosts and agents. >>>>>>>>> In some applications, the hosts can be completely decoupled = (agnostic about each other). I think it would be poor to add a = synchronization requirement just to support DOIC. >>>>>>>>> -Dave >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>>>>>>> lionel.morand@orange.com >>>>>>>>> Sent: Friday, August 01, 2014 6:58 AM >>>>>>>>> To: Steve Donovan; dime@ietf.org; Nirav Salot (nsalot) >>>>>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal Hi Steve, I = agree >>>>>>>>> with Nirav's view. >>>>>>>>> Regards, >>>>>>>>> Lionel >>>>>>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>>>>> ---- Nirav Salot (nsalot) a =E9crit ---- Steve, For this >>>>>>>>> issue, I don't agree to include identity of the DOIC node that = sends the report, into the realm reports. >>>>>>>>> In my view, the issue mentioned below - of two agents not = 100% synchronize w.r.t the realm-report - is the related to "how agents = synchronized between themselves" and since that is not standardized we = should not be developing protocol solution for the case which occurs due = to this out-of-standards solution. >>>>>>>>> Besides, I don't see any issue due to slight = miss-synchronization of the realm-reports between two agents since they = should still represent the realm load more or less accurately. >>>>>>>>> Also if the agents are not synchronized and if they are = playing the role of DOIC reacting node then they will apply abatement = algorithm based on different values (for the same realm). So it does not = matter if the client does the same. >>>>>>>>> Finally, I don't see any value-add of using the "identity = of >>>>>>>>> the node that sends the realm-report" to discard the other >>>>>>>>> report related to the same realm. In other words, this same >>>>>>>>> logic can be achieved using sequence-numbers as well, i.e. = when >>>>>>>>> the overload-report of an realm is active, the client is going >>>>>>>>> to ignore all the reports of the same realm which has lower >>>>>>>>> sequence number value. So in essence, when two agents are >>>>>>>>> sending realm-reports, one of the reports is automatically >>>>>>>>> ignored by the client if their sequence numbers differ. So the >>>>>>>>> outcome without including the "identity if the node that sends >>>>>>>>> realm report" is same as >>>>>>>>>> The effect should be that the reacting node will accept a = realm report from anyone when there is no active OLR for the realm but = it will only listen to one reporting node when it has an active report. >>>>>>>>> Regards, >>>>>>>>> Nirav. >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = Steve >>>>>>>>> Donovan >>>>>>>>> Sent: Friday, August 01, 2014 1:23 AM >>>>>>>>> To: dime@ietf.org >>>>>>>>> Subject: [Dime] DOIC issue #58 Proposal All, >>>>>>>>>=20 >>>>>>>>> Issue #58 deals with the fact that there can be multiple = senders of realm overload report for the same realm. >>>>>>>>>=20 >>>>>>>>> Ulrich proposes one aspect of what is required in the issue = description: >>>>>>>>>=20 >>>>>>>>> "In deployments where more than one node is configured to take = the role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness." >>>>>>>>>=20 >>>>>>>>> I agree with Ulrich that realm reports must include the = identity of the DOIC node that sends the report. This would be an = optional AVP only required for realm reports. It would not be required = for host reports as the identity of the sender of the host report is = implicitly defined by the origin-host in the answer message. >>>>>>>>>=20 >>>>>>>>> I also agree that the Diameter Identity of the reporting node = be used to determine if a received report is ignored or used to update = existing state. To this end I propose that we add wording that for the = duration of a realm report, the reacting node only listens for updates = to the realm report from from the DOIC node that sent the realm report = that resulted in the realm OCS being stored. >>>>>>>>>=20 >>>>>>>>> The effect should be that the reacting node will accept a = realm report from anyone when there is no active OLR for the realm but = it will only listen to one reporting node when it has an active report. >>>>>>>>>=20 >>>>>>>>> Steve >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> = ________________________________________________________________ >>>>>>>>> _ _ _______________________________________________________ >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>> informations confidentielles ou privilegiees et ne doivent = donc >>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si >>>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a = l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, 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. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> _______________________________________________ >>>> 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 >>>> 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. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=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 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >>=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Aug 7 11:53:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5725A1A03F4 for ; Thu, 7 Aug 2014 11:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8SeulVCcWUh for ; Thu, 7 Aug 2014 11:53:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642C21A0331 for ; Thu, 7 Aug 2014 11:53:14 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77IqMhC052196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:53:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 7 Aug 2014 13:53:11 -0500 X-Mao-Original-Outgoing-Id: 429130391.179358-87dfe793acadc917f6d86c87b4d02ffe Content-Transfer-Encoding: quoted-printable Message-Id: <6B14B407-F983-492D-AC2B-4185E7FB2B01@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <29455_1407331161_53E22B59_29455_3243_1_6B7134B31289DC4FAF731D844122B36E695089@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E24837.9080501@usdono! vans.com> <10660_1407338975_53E249DF_10660_1191_1_6B7134B31289DC4FAF731D844122B36E695497@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9RIOLuPwZJ894fWbnIU9zX3_34I Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:53:16 -0000 On Aug 6, 2014, at 10:29 AM, lionel.morand@orange.com wrote: > Hi Steve, >=20 > In that case it would mean that the proxy would not be any more = compliant with the application it is supposed to support and advertise = in CER/CEA. Only if said application is updated to _require_ DOIC (not merely allow = it.) From nobody Thu Aug 7 11:53:24 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337091A039C for ; Thu, 7 Aug 2014 11:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI5qMx693mo0 for ; Thu, 7 Aug 2014 11:53:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75991A035E for ; Thu, 7 Aug 2014 11:53:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77IqMhD052196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:53:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Thu, 7 Aug 2014 13:53:16 -0500 X-Mao-Original-Outgoing-Id: 429130396.730947-0a087a9d90f90a318ba27549ee44cf05 Content-Transfer-Encoding: quoted-printable Message-Id: <3EF96C84-2EE0-440C-AE43-EFD321C26110@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YdJbclXWUwz-MCitmDx3kSgDL7g Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:53:21 -0000 On Aug 5, 2014, at 12:51 PM, Nirav Salot (nsalot) = wrote: > Steve, >=20 > What is so difficult here and not sure why two operators are involved = since the proposal is restricted to change of behavior in either the = host or the agent at operator B? > Operator B has two choices: > - Turn off topology hiding in its agent since agents are not = supporting DOIC yet. > - Turn off generation of overload report at the host since topology = hiding is important. More likely, it means B uses DOIC in it's own network, but turns it off = for anything that passes the non-supporting topology-hiding proxy. This = requires some careful and complex configuration, and getting it wrong is = _bad_. >=20 > These are configuration related issue and interim/transient problems - = until the agents are upgraded to support DOIC. > So I don't think we need protocol solution for these types of = problems. Req 6 requires us to make a reasonable attempt to solve issues in the = protocol, rather than require people to configure around them. From nobody Thu Aug 7 11:53:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266DF1A036A for ; Thu, 7 Aug 2014 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBCzXW5EzA7w for ; Thu, 7 Aug 2014 11:53:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B30E1A0331 for ; Thu, 7 Aug 2014 11:53:29 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77IqMhE052196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:53:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53E0E7A8.2070501@usdonovans.com> Date: Thu, 7 Aug 2014 13:53:28 -0500 X-Mao-Original-Outgoing-Id: 429130408.347201-7cdb7bb45efe29e2abacc49c2ef0d378 Content-Transfer-Encoding: quoted-printable Message-Id: <9C14E606-8DB2-46FA-B700-4AEA56F69B7D@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <3789_1407243452_53E0D4BC_3789_4351_1_6B7134B31289DC4FAF731D844122B36E692D58@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53E0E7A8.2070501@usdonova! ns.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Swsth---NumQr_mJKPjo7p9dCwU Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:53:37 -0000 On Aug 5, 2014, at 9:18 AM, Steve Donovan = wrote: >>=20 >> Now, as for topology hiding, I think that any agent that will have to = change the Origin-Host of a message sent by a server will have to ensure = that such a modification has no impact on the normal process of the = message as if the message was sent from the server, whatever the = procedure. For instance, if there is any state linked to the origin-host = of the server, this agent will have to ensure that this state is = correctly managed afterwards when the origin-host is modified. This is = true for server selection as well as for overload control. > I don't disagree with what you are saying about proper implementation = of topology hiding. However, there is no normative definition of = topology hiding behavior that we can depend upon being followed. There = is also no way for an existing topology hiding agent to know how to = handle overload control. So any breakage that might happen from = existing topology hiding agents cannot be assumed away by saying that = the agent needs to properly handle overload control. It's really hard for a topology hiding agent to, in advance, avoid = breaking things that haven't been invented yet. And in this case, we are = not just talking about breaking DOIC, we are talking about an = interaction with DOIC that can make things behave worse than if DOIC was = not deployed at all. Normally, I would agree with you that, if you use topology hiding, = you've made your own bed and get to sleep in it. But unfortunately, the = use of topology hiding proxies is fairly pervasive, so being unable to = work across them is a pretty big problem for incremental deployment. You = either get "islands" of overload control split by the topology hiding = proxy, and a need for careful configuration to avoid accidentally = sending (or accepting) something across the non-supporting proxy. Also, we don't need full-blown topology hiding for this to be a problem. = Anything that modifies Origin-Host will cause it. (Remember the SFE = concept early in this work.) From nobody Thu Aug 7 11:54:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA50A1A030C for ; Thu, 7 Aug 2014 11:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H37e50oUiW6 for ; Thu, 7 Aug 2014 11:54:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7EC1A0331 for ; Thu, 7 Aug 2014 11:54:00 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77IqMhF052196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:53:53 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> Date: Thu, 7 Aug 2014 13:53:52 -0500 X-Mao-Original-Outgoing-Id: 429130432.761086-3983283f4db12cdacbd9e8ff1c2b82f3 Content-Transfer-Encoding: 7bit Message-Id: <86707927-C7BA-4214-80C4-6DF154F29D15@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qNaJXnt9BKnvRxeeEdqX1V45-SE Cc: "Shishufeng \(Susan\)" , "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:54:06 -0000 On Aug 5, 2014, at 2:22 AM, lionel.morand@orange.com wrote: > Exactly what I said :-) > Topology hiding is a non-issue. It is just a matter of configuration. > REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge be configured at each node. From nobody Thu Aug 7 11:59:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6C01A040E for ; Thu, 7 Aug 2014 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjFb-ht-2_Eb for ; Thu, 7 Aug 2014 11:58:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81731A04F6 for ; Thu, 7 Aug 2014 11:58:59 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77Iwv5O052819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Aug 2014 13:58:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: Ben Campbell Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 429130737.146404-9982301b262596fb17780f2a106534b8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Message-Id: Date: Thu, 7 Aug 2014 13:58:57 -0500 To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3NAQKs1uFZ8y4Z68YBTEdRGFKAs Subject: [Dime] OC-S-F in CER/CEA? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 18:59:01 -0000 Hi, We've discussed multiple issues where there _might_ be some benefit to = being able to detect if an immediate peer supports DOIC. One way to do = that would be to allow the inclusion of OC-S-F in CER/CEA messages. Do = we contemplate allowing (or forbidding) that? (Allowing OC-OLR is an = entirely different question.) Thanks! Ben. From nobody Thu Aug 7 21:45:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F75A1A01F6 for ; Thu, 7 Aug 2014 21:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96_J0_6QhH7K for ; Thu, 7 Aug 2014 21:45:02 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665551A01E8 for ; Thu, 7 Aug 2014 21:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1722; q=dns/txt; s=iport; t=1407473103; x=1408682703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wehPCzEaE2njrJOQeTUVXilS1i005+/NcHvwGXFtaqo=; b=mL48JJg6a2fAzNMDKk8ESF+kdK9a3zprZFxpWCg2uc8l1yUx/g5t3T26 ZvHiXR38BCDALDY/tddmCNnYSxqf2WiFx/3gw87NCyww4HH+Tj2j/gYNL YQBkFr5I9BQqaobsDWdz4WAHSo44PJAJNoHYGkSH6q8pMKwMYGuRV06Fh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAGRV5FOtJA2N/2dsb2JhbABagw2BKQTUHQGBExZ3hAMBAQEDATo/BQcEAgEIEQQBAQsUCQcyFAkIAgQOBQgTiB8IxBYXjAqDABExBwaDKYEcAQSxC4NXbIEGQA X-IronPort-AV: E=Sophos;i="5.01,822,1400025600"; d="scan'208";a="67526007" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 08 Aug 2014 04:45:02 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s784j1Nq031823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 04:45:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 23:45:01 -0500 From: "Nirav Salot (nsalot)" To: Ben Campbell Thread-Topic: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) Thread-Index: AQHPraL/wsfYguEi2UuaquJxy3rcB5u8buoAgAAOQgCAAIGHAIAEYa6AgABEAwD//9LCkIAAfXwAgABSJoCAAAh+QIADivcAgABQiCA= Date: Fri, 8 Aug 2014 04:45:00 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <3EF96C84-2EE0-440C-AE43-EFD321C26110@nostrum.com> In-Reply-To: <3EF96C84-2EE0-440C-AE43-EFD321C26110@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eIYbvOqKgkS5eFHLuncplMG_TCE Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Aug 2014 04:45:04 -0000 Ben, Here, we are talking about overload control between two operators - between= two PLMNs. And we already need to have configuration (however careful and complex it i= s) to share/expose overload report across operator's boundary. So I am not = talking about any new configuration on top of that, here, for the use case = we are trying to solve. Regards, Nirav.=20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Friday, August 08, 2014 12:23 AM To: Nirav Salot (nsalot) Cc: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58= Proposal) On Aug 5, 2014, at 12:51 PM, Nirav Salot (nsalot) wrote: > Steve, >=20 > What is so difficult here and not sure why two operators are involved sin= ce the proposal is restricted to change of behavior in either the host or t= he agent at operator B? > Operator B has two choices: > - Turn off topology hiding in its agent since agents are not supporting D= OIC yet. > - Turn off generation of overload report at the host since topology hidin= g is important. More likely, it means B uses DOIC in it's own network, but turns it off for= anything that passes the non-supporting topology-hiding proxy. This requir= es some careful and complex configuration, and getting it wrong is _bad_. >=20 > These are configuration related issue and interim/transient problems - un= til the agents are upgraded to support DOIC. > So I don't think we need protocol solution for these types of problems. Req 6 requires us to make a reasonable attempt to solve issues in the proto= col, rather than require people to configure around them. From nobody Thu Aug 7 22:11:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BE71A028A for ; Thu, 7 Aug 2014 22:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_rQ-7ou4m3x for ; Thu, 7 Aug 2014 22:11:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888911A01E8 for ; Thu, 7 Aug 2014 22:11:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s785BCQc006503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 00:11:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Fri, 8 Aug 2014 00:11:11 -0500 X-Mao-Original-Outgoing-Id: 429167471.80197-96f89fec8144c1e8d2037b866001af6d Content-Transfer-Encoding: quoted-printable Message-Id: <60B5C9FF-806C-4F3D-ADFB-AAFF69147E54@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com>, <31607_1406890704_53DB72D0_31607_3583_1_6jqjx92pvkh7ceh3vosxad66.1406890698315@email.android.com> <53DBBBBA.3060200@usdonovans.com> <53DBF04E.2050005@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61C69@SZXEMA512-MBX.china.huawei.com> <3AAAFD81-DB6C-4B3E-8F22-2FB357D9427A@nostrum.com> <26C84DFD55BC3040A45BF70926E55F258DF62078@SZXEMA512-MBX.china.huawei.com>, <4738_1407223364_53E08644_4738_3164_1_v7vrg2ymelvonbai1iwvomjs.1407223357026@email.android.com> <53E0CB2B.8080207@usdonovans.com> <3EF96C84-2EE0-440C-AE43-EFD321C26110@nostrum.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R-EJv1kGdsFnbyn7eMCUuiJ-MvM Cc: "dime@ietf.org" Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Aug 2014 05:11:26 -0000 The two operator aspect was just an example. The use cases for this = problem are in no way limited to inter-operator cases. Another very common example would be a non-DOIC supporting = server-front-end proxy, as we talked about in the early days of this = draft. Or a commonly deployed approach to the central proxy in policy = applications. On Aug 7, 2014, at 11:45 PM, Nirav Salot (nsalot) = wrote: > Ben, >=20 > Here, we are talking about overload control between two operators - = between two PLMNs. > And we already need to have configuration (however careful and complex = it is) to share/expose overload report across operator's boundary. So I = am not talking about any new configuration on top of that, here, for the = use case we are trying to solve. >=20 > Regards, > Nirav.=20 >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Friday, August 08, 2014 12:23 AM > To: Nirav Salot (nsalot) > Cc: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC = issue #58 Proposal) >=20 >=20 > On Aug 5, 2014, at 12:51 PM, Nirav Salot (nsalot) = wrote: >=20 >> Steve, >>=20 >> What is so difficult here and not sure why two operators are involved = since the proposal is restricted to change of behavior in either the = host or the agent at operator B? >> Operator B has two choices: >> - Turn off topology hiding in its agent since agents are not = supporting DOIC yet. >> - Turn off generation of overload report at the host since topology = hiding is important. >=20 > More likely, it means B uses DOIC in it's own network, but turns it = off for anything that passes the non-supporting topology-hiding proxy. = This requires some careful and complex configuration, and getting it = wrong is _bad_. >=20 >>=20 >> These are configuration related issue and interim/transient problems = - until the agents are upgraded to support DOIC. >> So I don't think we need protocol solution for these types of = problems. >=20 > Req 6 requires us to make a reasonable attempt to solve issues in the = protocol, rather than require people to configure around them. >=20 From nobody Fri Aug 8 07:34:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37151B2B38 for ; Fri, 8 Aug 2014 07:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zebo27aY0rDD for ; Fri, 8 Aug 2014 07:33:58 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0890D1B2B23 for ; Fri, 8 Aug 2014 07:33:58 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so7372709pad.41 for ; Fri, 08 Aug 2014 07:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nHWcX84lWlsITH+gPN7GL/TWRMVOFP/9BrRjWDwAQ4c=; b=0g1bEt9yNfYj3AO8JfuDPMMNoRRAsy38NItgWCaq/oxy7tJzv6vKKfzKGhrLIlSXNd B5reI7+7pQjFxRumP6PPUzXhxDv2ic/Pf70RkuIEZbCpLi3NgQzQIXeu7C9hypxkx8+w kD90Xh4Ajk7GD6tcR1nTEEq7puCJ9dCF00HQdLrMYZaOfkG/dNEA43gKaTan/GYRXe4J 8zeKW5Bmyo6jhIunbeJXa3LsbA0IR7tYBzaO3QAn1976tfhEoyilCGc0c0Qa1fb2fvkc tbLhUYxZOXmZ9m8pS/Vx3M/oH5ox6CBGtySe/5whFcp1ZosDli4tWhI7EYbhevKtqmob 7rvQ== MIME-Version: 1.0 X-Received: by 10.69.31.65 with SMTP id kk1mr1904244pbd.162.1407508437743; Fri, 08 Aug 2014 07:33:57 -0700 (PDT) Received: by 10.70.3.3 with HTTP; Fri, 8 Aug 2014 07:33:57 -0700 (PDT) Date: Fri, 8 Aug 2014 10:33:57 -0400 Message-ID: From: Andrew Booth To: "dime@ietf.org" Content-Type: multipart/alternative; boundary=001a11369c06733db705001f18c7 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hepg8zCxY1pSREaOC72uDrTAcls Subject: [Dime] Diameter Message Maximum Length X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Aug 2014 14:33:59 -0000 --001a11369c06733db705001f18c7 Content-Type: text/plain; charset=UTF-8 Hi, I have a couple of questions about maximum message size in Diameter. A Diameter message header has a 3 byte length indicator, so a maximum message length of 16777215. I don't see any way for Diameter node to advertise support for a smaller message length. Does that mean that a node is expected to support a message length up to 0xffffff? Or is it free to impose its own upper limit and reject (send an error) if the message is too long? Meanwhile, in RFC6083 (DTLS/SCTP): However, the following limitations still apply: o The maximum user message size is 2^14 bytes, which is the DTLS limit. Am I reading this correctly that this limits Diameter message lengths to 2^14 when using DTLS/SCTP? Or is there some kind of workaround to this limitation? Thanks for any info, Andrew --001a11369c06733db705001f18c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a couple of questions about maximum= message size in Diameter.

A Diameter message header has a 3 byte le= ngth indicator, so a maximum message length of 16777215.=C2=A0 I don't = see any way for Diameter node to advertise support for a smaller message le= ngth.=C2=A0 Does that mean that a node is expected to support a message len= gth up to 0xffffff?=C2=A0 Or is it free to impose its own upper limit and r= eject (send an error) if the message is too long?

Meanwhile, in RFC6083 (DTLS/SCTP):
=C2=A0 =C2=A0 =C2=A0=C2=A0 Howeve= r, the following limitations still apply:

=C2=A0 =C2=A0 =C2=A0=C2=A0= o=C2=A0 The maximum user message size is 2^14 bytes, which is the DTLS
= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 limit.

Am I reading th= is correctly that this limits Diameter message lengths to 2^14 when using D= TLS/SCTP?=C2=A0 Or is there some kind of workaround to this limitation?

Thanks for any info,
Andrew
--001a11369c06733db705001f18c7-- From nobody Fri Aug 8 07:48:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222201B2B07 for ; Fri, 8 Aug 2014 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_lBMasvDOPB for ; Fri, 8 Aug 2014 07:48:28 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2E21B2AFA for ; Fri, 8 Aug 2014 07:48:28 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52904 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XFlSz-00061x-Q1 for dime@ietf.org; Fri, 08 Aug 2014 07:48:27 -0700 Message-ID: <53E4E339.1070106@usdonovans.com> Date: Fri, 08 Aug 2014 09:48:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZcSIBbQWh8A57gSU4tTysQbu8fc Subject: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Aug 2014 14:48:30 -0000 All, The issue with pre-DOIC agents changing origin-host was been discussed in this thread: http://www.ietf.org/mail-archive/web/dime/current/msg07618.html One example of the impact of the issue is defined in this message: http://www.ietf.org/mail-archive/web/dime/current/msg07660.html So far three solutions have been discussed for this issue: 1) Attribution of overload reports. - Add diameter-id of the node that is overloaded into the OC-OLR AVP. - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. I've compiled a starting point for a pros and cons analysis of the three approaches. Regards, Steve --------- Option 1 Pros: ------------ - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. Option 1 Cons: ------------- - Requires additional protocol machinery (minimal) - Does not completely fix the effects of non-DOIC agent on overload control Option 2 Pros: ------------ - Does not require additional protocol machinery - Does the best job of three alternatives in allowing for management of overload conditions Option 2 Cons: ------------ - Requires the operator to lose any functionality enabled by the non-DOIC agent until all agents have been upgraded to support DOIC - Requires extra configuration (against requirement #6) - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. Option 3 Pros: ------------ - Does not require additional protocol machinery - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. Option 3 Cons: ------------ - Requires extra configuration (against requirement #6) - Likely requires extra development in the reporting node that would not otherwise be needed (ability to limit where overload reports are sent) - Not necessarily easy to determine in advance where which requests will traverse a the non-DOIC agent - Limits ability of operator to fully control overload From nobody Fri Aug 8 11:43:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7761A0067 for ; Fri, 8 Aug 2014 11:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdjoXuhVFvJy for ; Fri, 8 Aug 2014 11:43:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF2D1A0084 for ; Fri, 8 Aug 2014 11:43:10 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s78Ih2kk097820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 13:43:09 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53E4E339.1070106@usdonovans.com> Date: Fri, 8 Aug 2014 13:43:02 -0500 X-Mao-Original-Outgoing-Id: 429216182.321303-8bffa6ac790124bf5ca451c73081ead5 Content-Transfer-Encoding: quoted-printable Message-Id: <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> References: <53E4E339.1070106@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mJ963eK_5h-wr4MIqGTikTNnGOY Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Aug 2014 18:43:39 -0000 On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: > All, >=20 > The issue with pre-DOIC agents changing origin-host was been discussed = in this thread: >=20 > http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >=20 > One example of the impact of the issue is defined in this message: >=20 > http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >=20 > So far three solutions have been discussed for this issue: >=20 > 1) Attribution of overload reports. > - Add diameter-id of the node that is overloaded into the OC-OLR AVP. > - Reacting node always uses the diameter-id in the OC-OLR report when = applying abatement algorithm logic. > - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there = is a difference, the reacting node should report on the condition = (event/alarm). Local policy would determine if the reacting node honors = the overload report or ignores the overload report. I think the last entry is worth further discussion, but it's probably = more important to make a high level decision first. But, at risk of = getting ahead of myself: I have trouble imagining a situation where = honoring the overload report will be harmful, since if there is an = intervening OHMA, the reacting node will not likely have any host-routed = requests to the diameter-id from the OLR. OTOH, I have trouble imagining = where honoring the report would be useful, for the same reason. >=20 > 2) Configuration in operator's networks to turn off origin-host = munging behavior until the agent is upgraded to support DOIC. >=20 > 3) Configuration of reporting nodes to not send overload reports, = either universally or for transactions that cross the origin-host = munging agent. >=20 > I've compiled a starting point for a pros and cons analysis of the = three approaches. >=20 > Regards, >=20 > Steve >=20 > --------- >=20 > Option 1 Pros: > ------------ > - Gives operators a mechanism to detect when there is a non-DOIC = origin-host-munging agent in the path of a transaction. > - Gives operators ability to manage the under utilization issue caused = by the non-DOIC agent. > - Gives operators the ability to keep features requiring origin-host = munging turned on while DOIC is rolled out. > - Leaves the determination of which action to take in this scenario = (honor or ignore overload reports) to operator policy. > - Addresses RFC 7068 requirement #6 on minimizing the amount of = configuration required. > - Addresses RFC 7068 requirement #12 on minimizing the impact of a = single node overload on the traffic handled by other nodes in the = network. > - Addresses RFC 7068 requirement #17 on minimizing the impact of = overload in a mixed DOIC environment on the overall capacity of the = network. Specifically, it complies with the MUST NOT make things worth clause, = but does not comply with the SHOULD reduce overload clause. >=20 > Option 1 Cons: > ------------- > - Requires additional protocol machinery (minimal) > - Does not completely fix the effects of non-DOIC agent on overload = control One additional con is that, if the OHMA is there for the purposes of = true topology hiding, the identity in the OLR may leak topology = information. >=20 > Option 2 Pros: > ------------ > - Does not require additional protocol machinery > - Does the best job of three alternatives in allowing for management = of overload conditions >=20 > Option 2 Cons: > ------------ > - Requires the operator to lose any functionality enabled by the = non-DOIC agent until all agents have been upgraded to support DOIC > - Requires extra configuration (against requirement #6) > - There is not way to determine if all non-DOIC origin-host munging = behavior has been turned off until an overload event happens, with = potential to have significant negative effects until the offending agent = can be found and the behavior turned off. > - Not always possible, as operator doesn't always have control over = non-DOIC agent as it might be in another operators network. Proposal to = address this through interop agreements but while this might work in = 3GPP scenarios, not all Diameter deployments are 3GPP driven. Since you mentioned the 7068 requirements in the cons for option 1, it = makes sense to mention them for others. This one misses on 6, but seems = okay for 12 and 17. (I guess we should have had a requirement about not = interfering with existing network features. If we had that, Option 2 = would not comply.) >=20 > Option 3 Pros: > ------------ > - Does not require additional protocol machinery > - Gives operators the ability to keep features requiring origin-host = munging turned on while DOIC is rolled out. For very limited definitions of "rolled out." >=20 > Option 3 Cons: > ------------ > - Requires extra configuration (against requirement #6) > - Likely requires extra development in the reporting node that would = not otherwise be needed (ability to limit where overload reports are = sent) > - Not necessarily easy to determine in advance where which requests = will traverse a the non-DOIC agent > - Limits ability of operator to fully control overload >=20 Seems to miss req 6 even worse than for option 2. Misses 17 in a similar = way as option 1. Partially misses 34. From nobody Tue Aug 12 13:05:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275B31A06ED for ; Tue, 12 Aug 2014 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIDvkB8T3AkL for ; Tue, 12 Aug 2014 13:05:27 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1941A00D1 for ; Tue, 12 Aug 2014 13:05:27 -0700 (PDT) Received: from ip-64-134-29-86.public.wayport.net ([64.134.29.86]:53750 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHIJt-0004u9-Gi; Tue, 12 Aug 2014 13:05:25 -0700 Message-ID: <53EA7373.90404@usdonovans.com> Date: Tue, 12 Aug 2014 15:05:07 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> In-Reply-To: <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6Pus41azmOwknAMtTHB1pGW4JO0 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 20:05:29 -0000 Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? Steve On 8/8/14, 1:43 PM, Ben Campbell wrote: > On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: > >> All, >> >> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >> >> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >> >> One example of the impact of the issue is defined in this message: >> >> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >> >> So far three solutions have been discussed for this issue: >> >> 1) Attribution of overload reports. >> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. > I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. > >> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >> >> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >> >> I've compiled a starting point for a pros and cons analysis of the three approaches. >> >> Regards, >> >> Steve >> >> --------- >> >> Option 1 Pros: >> ------------ >> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. > Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. > >> Option 1 Cons: >> ------------- >> - Requires additional protocol machinery (minimal) >> - Does not completely fix the effects of non-DOIC agent on overload control > One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. > >> Option 2 Pros: >> ------------ >> - Does not require additional protocol machinery >> - Does the best job of three alternatives in allowing for management of overload conditions >> >> Option 2 Cons: >> ------------ >> - Requires the operator to lose any functionality enabled by the non-DOIC agent until all agents have been upgraded to support DOIC >> - Requires extra configuration (against requirement #6) >> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. > Since you mentioned the 7068 requirements in the cons for option 1, it makes sense to mention them for others. This one misses on 6, but seems okay for 12 and 17. (I guess we should have had a requirement about not interfering with existing network features. If we had that, Option 2 would not comply.) > >> Option 3 Pros: >> ------------ >> - Does not require additional protocol machinery >> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. > For very limited definitions of "rolled out." > >> Option 3 Cons: >> ------------ >> - Requires extra configuration (against requirement #6) >> - Likely requires extra development in the reporting node that would not otherwise be needed (ability to limit where overload reports are sent) >> - Not necessarily easy to determine in advance where which requests will traverse a the non-DOIC agent >> - Limits ability of operator to fully control overload >> > Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. > > From nobody Tue Aug 12 13:45:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112491A0008 for ; Tue, 12 Aug 2014 13:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCs1UROct8_o for ; Tue, 12 Aug 2014 13:45:50 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CB51A004D for ; Tue, 12 Aug 2014 13:45:50 -0700 (PDT) Received: from ip-64-134-29-86.public.wayport.net ([64.134.29.86]:53820 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHIx1-0002Q5-DL for dime@ietf.org; Tue, 12 Aug 2014 13:45:48 -0700 Message-ID: <53EA7CFB.8090407@usdonovans.com> Date: Tue, 12 Aug 2014 15:45:47 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hfy4j4out1eMfrakGGoH83XlvZI Subject: [Dime] Issue #35 Resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 20:45:54 -0000 All, It was re-affirmed at the Toronto meeting that this issue would be addressed through a future extension to DOIC. As such, I plan to close the issue. Regards, Steve From nobody Thu Aug 14 13:20:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5131A0683; Thu, 14 Aug 2014 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAEQcsf-hkqI; Thu, 14 Aug 2014 13:20:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7201A0380; Thu, 14 Aug 2014 13:20:33 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7EKKUvo083415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Aug 2014 15:20:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Thu, 14 Aug 2014 15:20:30 -0500 X-Mao-Original-Outgoing-Id: 429740430.018919-a5b7ed8f6c31e5aa6dd4e9f305f4857f Content-Transfer-Encoding: quoted-printable Message-Id: <63919F1E-5772-4337-BCCE-98263A50D1E3@nostrum.com> To: draft-ietf-core-groupcomm.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KRHaSpvOmIzW5JUX4MXzCIpmiNY Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" , "dime@ietf.org list" Subject: [Dime] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Aug 2014 20:20:35 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-core-groupcomm-21 Reviewer: Ben Campbell Review Date: 2014-08-14 IETF LC End Date: 2014-08-14 IESG Telechat date:=20 Summary: This draft is not ready for publication as an informational = RFC. It has some significant issues, detailed below. **** Major issues: -- The draft contains significant material that I do not believe is = appropriate for an informational RFC, at least without some clear = explanations about why it appears. It purports to clarify the normative = stuff in RFC 7252 concerning multicast, but it does quite a bit more = than that. Section 2.7 defines protocol, in the form of a RESTful methods and = attributes to manage multicast group membership.I agree in some cases it = makes sense for an informational RFC to define protocol. A common = example is when we want to document a proprietary protocol for some = reason. As written, this does not seem to fall unto such a case. If the = authors and working group believe it does, it would be helpful to add = text explaining that, and how the reader should interpret the section. = (I recognize that this interface is optional--but I don't think making = it optional changes whether it should be standards track.) In addition to that, the draft contains quite a bit of guidance that = might be more appropriate BCP. For example, there is guidance here where = not following it might do harm to the network. Additionally, I don't see = how anyone could expect to achieve interoperability the multicast = features of RFC 7252 without understanding this draft. (I have to = wonder why RFC 7252 did not have a normative dependency on this draft.) -- The security aspects of group CoAP are pretty bad. To its credit, the = draft does a pretty good job of calling that out, and that work is in = progress to improve it. But I have to wonder if we would be better off = not encouraging multicast CoAP at all until such improvements are = available. Section 5.3 calls out some reasonable examples of mitigation = approaches, but I am a little concerned at the guidance that one should = worry about these for "sensitive" or "safety-critical" data. People are = not good at knowing what data is "sensitive" until it gets used against = them. I think this is especially true for IoT applications where we have = less deployment experience. Along those lines, the Pervasive Monitoring Considerations section = (kudos for having one, btw), tries to balance application needs vs = protecting information. But the smart-grid example seems to be a case = where the two are really at odds. I am afraid people will interpret this = along the lines of "well, the smart-grid application requirements force = me to send unprotected data all over the place", when I think the right = answer is "Group CoAP should not be used for this sort of application = until we can protect the data". **** Minor issues: -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the = IP multicast address literal in a group URI." Can you elaborate on why? I can guess, but anytime we suggest using = literal IP addresses rather than DNS names, it's worth elaborating. -- 2.4: " ... if the resource being POSTed to has been designed to cope = with the unreliable and lossy nature of IP multicast." Can you elaborate on what it means to be "designed to cope..."? (Or = reference something that does?) -- 2.6: I think the Resource Directory reference needs to be normative. (I see = the discussion of this from Barry's AD review, where the authors argued = that the reference is optional for implementations. But our definition = of normative references also includes things necessary to fully = understand this draft. Fully understanding even optional features is = part of that.) -- 2.7.1, 2nd paragraph: Does this imply a need to coordinate pre-configured group addresses to = avoid collisions? -- 2.7.2.1: 2nd 2 last paragraph: Are there any scenarios where a missing port might be determined from = DNS, rather than just assuming the default? -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete = or update group membership objects for which the CoAP client, invoking = this operation, is responsible" Do I understand correctly that this replaces the entire set? Is it = possible for two different clients to be responsible for two different = subsets? If so, how? -- 2.8 and (especially) 2.9: Lack of 2119 language in the "additional guidlines" seems inconsistent = with other parts of this draft that do use 2119 language. (I agree the = places where you talk about what 7252 already says should not use 2119 = language.) I can maybe see the difference for 2.8, but the = congestion-avoidance stuff in 2.9 seems as appropriate for 2119 language = as most anything else in the draft. (To be clear, I'm not suggesting more or less normative language--only = consistency in its use.) **** Nits/editorial comments: -- Abstract: Please expand CoAP on first use in abstract. (But don't remove the = expansion in the body.) -- 2.2, 4th paragraph: " ... it is recommended ..."=20 Was that intended as normative?=20 Along those lines, I see a number of sections where 2119 words are used = in lower case where it looks like they were not intended as normative = (e.g., where you talk about normative requirements from RFC 7252), but = in other areas it's not as clear (like this one.) It would be best to = either avoid lower case versions of 2119 words, or make it very clear = whether they should be interpreted normatively or not. -- 2.7.2, 2nd paragraph: Wording is confusing. Do you mean MUST use the DTLS method, or MUST use = some method, with DTLS an option? Sentence seems to mean the former, in = which it would be more clear to say "MUST use DTLS as described in ..." -- 2.7.2.1, 3rd paragraph: Please expand JDON on first use. -- 2.7.2.1, paragraph after examples: You mention an optional port for "a" attributes, but not for "n" = attributes. The BNF for group-name seems to allow an optional port. (and = you mention an optional port for "n" later. From nobody Thu Aug 14 14:02:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E291A87A6; Thu, 14 Aug 2014 14:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC0CduThjyTz; Thu, 14 Aug 2014 14:02:05 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD8E1A87A5; Thu, 14 Aug 2014 14:02:04 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so1690994lab.34 for ; Thu, 14 Aug 2014 14:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rCrUy1k9I9f1xbaa4SCc1ZR6Tjia/v2MtKx9zmruU7w=; b=peivroQ6+8pKVYlXB+7wDqWg4UY/jmksceu/zT1xzBv9BDBZ8oKdXv9m9zLWp3hHVz UqqEsnTaoSypplcwowRl+ufhUqtdOepXih5xm/rUN9Q65a+TLkM4GASzJdlvTgirq6Aw etuU49VQU8p6NLk0xEsPZyIqlge/UEElkA0w4Z3DpTRyQbTHP5SGWtKJjNT8hKeiZQcZ 8s10veYPPCOpqU3Pi1aF6uCCOLMJJ5L6mFjWCfmiZFfIi6lDtIrp4tZtnfeflI9MOTQ+ FJsz0/dnw/9zN7AwZMPQXBtCWGzNoajdN3Atv+gGm81l1a+rvLCVpAkPCrkq77tEs86H Riqg== MIME-Version: 1.0 X-Received: by 10.152.5.42 with SMTP id p10mr6736836lap.82.1408050122526; Thu, 14 Aug 2014 14:02:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 14 Aug 2014 14:02:02 -0700 (PDT) In-Reply-To: <63919F1E-5772-4337-BCCE-98263A50D1E3@nostrum.com> References: <63919F1E-5772-4337-BCCE-98263A50D1E3@nostrum.com> Date: Thu, 14 Aug 2014 17:02:02 -0400 X-Google-Sender-Auth: XEni78Y7kRZrHlh0cum_JF-TUvQ Message-ID: From: Barry Leiba To: Ben Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Qe9wViNX7KHsHgwsHCzKIBSUCcE Cc: "dime@ietf.org list" , "gen-art@ietf.org Team \(gen-art@ietf.org\)" , "draft-ietf-core-groupcomm.all@tools.ietf.org" Subject: Re: [Dime] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Aug 2014 21:02:07 -0000 Hi, Ben, and thanks for the review. Did you send it to the "dime" list by accident, instead of to the "core" list? In any case, would you please re-send it to include the "core" list (along with the other addresses as well, so that reply-all works)? Thanks. Barry On Thu, Aug 14, 2014 at 4:20 PM, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-core-groupcomm-21 > Reviewer: Ben Campbell > Review Date: 2014-08-14 > IETF LC End Date: 2014-08-14 > IESG Telechat date: > > Summary: This draft is not ready for publication as an informational RFC.= It has some significant issues, detailed below. > > **** Major issues: > > -- The draft contains significant material that I do not believe is appro= priate for an informational RFC, at least without some clear explanations a= bout why it appears. It purports to clarify the normative stuff in RFC 7252= concerning multicast, but it does quite a bit more than that. > > Section 2.7 defines protocol, in the form of a RESTful methods and attrib= utes to manage multicast group membership.I agree in some cases it makes se= nse for an informational RFC to define protocol. A common example is when w= e want to document a proprietary protocol for some reason. As written, this= does not seem to fall unto such a case. If the authors and working group b= elieve it does, it would be helpful to add text explaining that, and how th= e reader should interpret the section. (I recognize that this interface is = optional--but I don't think making it optional changes whether it should be= standards track.) > > In addition to that, the draft contains quite a bit of guidance that migh= t be more appropriate BCP. For example, there is guidance here where not fo= llowing it might do harm to the network. Additionally, I don't see how anyo= ne could expect to achieve interoperability the multicast features of RFC 7= 252 without understanding this draft. (I have to wonder why RFC 7252 did n= ot have a normative dependency on this draft.) > > -- The security aspects of group CoAP are pretty bad. To its credit, the = draft does a pretty good job of calling that out, and that work is in progr= ess to improve it. But I have to wonder if we would be better off not encou= raging multicast CoAP at all until such improvements are available. Section= 5.3 calls out some reasonable examples of mitigation approaches, but I am = a little concerned at the guidance that one should worry about these for "s= ensitive" or "safety-critical" data. People are not good at knowing what da= ta is "sensitive" until it gets used against them. I think this is especial= ly true for IoT applications where we have less deployment experience. > > Along those lines, the Pervasive Monitoring Considerations section (kudos= for having one, btw), tries to balance application needs vs protecting inf= ormation. But the smart-grid example seems to be a case where the two are r= eally at odds. I am afraid people will interpret this along the lines of "w= ell, the smart-grid application requirements force me to send unprotected d= ata all over the place", when I think the right answer is "Group CoAP shoul= d not be used for this sort of application until we can protect the data". > > > > > **** Minor issues: > > -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the I= P multicast address literal in a group URI." > > Can you elaborate on why? I can guess, but anytime we suggest using liter= al IP addresses rather than DNS names, it's worth elaborating. > > -- 2.4: " ... if the resource being POSTed to has been designed to cope w= ith the unreliable and lossy nature of IP multicast." > > Can you elaborate on what it means to be "designed to cope..."? (Or refer= ence something that does?) > > -- 2.6: > > I think the Resource Directory reference needs to be normative. (I see t= he discussion of this from Barry's AD review, where the authors argued that= the reference is optional for implementations. But our definition of norma= tive references also includes things necessary to fully understand this dra= ft. Fully understanding even optional features is part of that.) > > -- 2.7.1, 2nd paragraph: > > Does this imply a need to coordinate pre-configured group addresses to av= oid collisions? > > -- 2.7.2.1: 2nd 2 last paragraph: > > Are there any scenarios where a missing port might be determined from DNS= , rather than just assuming the default? > > -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete or= update group membership objects for which the CoAP client, invoking this o= peration, is responsible" > > Do I understand correctly that this replaces the entire set? Is it possib= le for two different clients to be responsible for two different subsets? I= f so, how? > > -- 2.8 and (especially) 2.9: > > Lack of 2119 language in the "additional guidlines" seems inconsistent wi= th other parts of this draft that do use 2119 language. (I agree the places= where you talk about what 7252 already says should not use 2119 language.)= I can maybe see the difference for 2.8, but the congestion-avoidance stuff= in 2.9 seems as appropriate for 2119 language as most anything else in the= draft. > > (To be clear, I'm not suggesting more or less normative language--only co= nsistency in its use.) > > > > > **** Nits/editorial comments: > > -- Abstract: > > Please expand CoAP on first use in abstract. (But don't remove the expans= ion in the body.) > > -- 2.2, 4th paragraph: " ... it is recommended ..." > > Was that intended as normative? > > Along those lines, I see a number of sections where 2119 words are used i= n lower case where it looks like they were not intended as normative (e.g.,= where you talk about normative requirements from RFC 7252), but in other a= reas it's not as clear (like this one.) It would be best to either avoid lo= wer case versions of 2119 words, or make it very clear whether they should = be interpreted normatively or not. > > -- 2.7.2, 2nd paragraph: > > Wording is confusing. Do you mean MUST use the DTLS method, or MUST use s= ome method, with DTLS an option? Sentence seems to mean the former, in whic= h it would be more clear to say "MUST use DTLS as described in ..." > > -- 2.7.2.1, 3rd paragraph: > > Please expand JDON on first use. > > -- 2.7.2.1, paragraph after examples: > > You mention an optional port for "a" attributes, but not for "n" attribut= es. The BNF for group-name seems to allow an optional port. (and you mentio= n an optional port for "n" later. > > > From nobody Thu Aug 14 14:07:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDFD1A87B8 for ; Thu, 14 Aug 2014 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU6uAs4uMQeg for ; Thu, 14 Aug 2014 14:07:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A987D1A87BB for ; Thu, 14 Aug 2014 14:07:04 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7EL6QWB087315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Aug 2014 16:07:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Thu, 14 Aug 2014 16:07:03 -0500 X-Mao-Original-Outgoing-Id: 429743223.09628-bc70363a7ea15e7c0ffcdcb248f56cac Content-Transfer-Encoding: quoted-printable Message-Id: References: <63919F1E-5772-4337-BCCE-98263A50D1E3@nostrum.com> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QYVqvMyUCYi8K0rPTnwmCBnLgRw Subject: [Dime] Fwd: Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Aug 2014 21:07:18 -0000 Oops, sorry, I sent that to the wrong list. Please ignore. Begin forwarded message: > From: Ben Campbell > Subject: Gen-ART LC Review of draft-ietf-core-groupcomm-21 > Date: August 14, 2014 at 3:20:30 PM CDT > To: draft-ietf-core-groupcomm.all@tools.ietf.org > Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" , = "dime@ietf.org list" >=20 [...] From nobody Sat Aug 16 10:30:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB551A007B; Sat, 16 Aug 2014 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p4XopT43vLK; Sat, 16 Aug 2014 10:30:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C30B31A0026; Sat, 16 Aug 2014 10:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140816173025.9259.54362.idtracker@ietfa.amsl.com> Date: Sat, 16 Aug 2014 10:30:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KqrFK7rl7kDwGiwWiyiXhB_xVOo Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-26.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 17:30:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Authors : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-26.txt Pages : 27 Date : 2014-08-16 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-26 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 nobody Mon Aug 18 15:01:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349B21A8030 for ; Mon, 18 Aug 2014 15:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLttn8dsZQFY for ; Mon, 18 Aug 2014 15:01:35 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EF71A7D82 for ; Mon, 18 Aug 2014 15:01:35 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64103 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJUzZ-0001qh-Jc for dime@ietf.org; Mon, 18 Aug 2014 15:01:33 -0700 Message-ID: <53F277B9.1060509@usdonovans.com> Date: Mon, 18 Aug 2014 17:01:29 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> In-Reply-To: <53EA7373.90404@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/brUXNT4uu5gr5IDRwBBI2kBYs2s Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 18 Aug 2014 22:01:36 -0000 All, My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. If we can get agreement on this then we can start making progress on the remainder of the document. Steve On 8/12/14, 3:05 PM, Steve Donovan wrote: > Are there other thoughts on the pros and cons of the three proposals > for resolution of issue #66? > > Steve > > On 8/8/14, 1:43 PM, Ben Campbell wrote: >> On Aug 8, 2014, at 9:48 AM, Steve Donovan >> wrote: >> >>> All, >>> >>> The issue with pre-DOIC agents changing origin-host was been >>> discussed in this thread: >>> >>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>> >>> One example of the impact of the issue is defined in this message: >>> >>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>> >>> So far three solutions have been discussed for this issue: >>> >>> 1) Attribution of overload reports. >>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>> - Reacting node always uses the diameter-id in the OC-OLR report >>> when applying abatement algorithm logic. >>> - Reacting node detects when there is a difference between the >>> diameter-id in the OC-OLR report and in the Origin-Host AVP. When >>> there is a difference, the reacting node should report on the >>> condition (event/alarm). Local policy would determine if the >>> reacting node honors the overload report or ignores the overload >>> report. >> I think the last entry is worth further discussion, but it's probably >> more important to make a high level decision first. But, at risk of >> getting ahead of myself: I have trouble imagining a situation where >> honoring the overload report will be harmful, since if there is an >> intervening OHMA, the reacting node will not likely have any >> host-routed requests to the diameter-id from the OLR. OTOH, I have >> trouble imagining where honoring the report would be useful, for the >> same reason. >> >>> 2) Configuration in operator's networks to turn off origin-host >>> munging behavior until the agent is upgraded to support DOIC. >>> >>> 3) Configuration of reporting nodes to not send overload reports, >>> either universally or for transactions that cross the origin-host >>> munging agent. >>> >>> I've compiled a starting point for a pros and cons analysis of the >>> three approaches. >>> >>> Regards, >>> >>> Steve >>> >>> --------- >>> >>> Option 1 Pros: >>> ------------ >>> - Gives operators a mechanism to detect when there is a non-DOIC >>> origin-host-munging agent in the path of a transaction. >>> - Gives operators ability to manage the under utilization issue >>> caused by the non-DOIC agent. >>> - Gives operators the ability to keep features requiring origin-host >>> munging turned on while DOIC is rolled out. >>> - Leaves the determination of which action to take in this scenario >>> (honor or ignore overload reports) to operator policy. >>> - Addresses RFC 7068 requirement #6 on minimizing the amount of >>> configuration required. >>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a >>> single node overload on the traffic handled by other nodes in the >>> network. >>> - Addresses RFC 7068 requirement #17 on minimizing the impact of >>> overload in a mixed DOIC environment on the overall capacity of the >>> network. >> Specifically, it complies with the MUST NOT make things worth clause, >> but does not comply with the SHOULD reduce overload clause. >> >>> Option 1 Cons: >>> ------------- >>> - Requires additional protocol machinery (minimal) >>> - Does not completely fix the effects of non-DOIC agent on overload >>> control >> One additional con is that, if the OHMA is there for the purposes of >> true topology hiding, the identity in the OLR may leak topology >> information. >> >>> Option 2 Pros: >>> ------------ >>> - Does not require additional protocol machinery >>> - Does the best job of three alternatives in allowing for management >>> of overload conditions >>> >>> Option 2 Cons: >>> ------------ >>> - Requires the operator to lose any functionality enabled by the >>> non-DOIC agent until all agents have been upgraded to support DOIC >>> - Requires extra configuration (against requirement #6) >>> - There is not way to determine if all non-DOIC origin-host munging >>> behavior has been turned off until an overload event happens, with >>> potential to have significant negative effects until the offending >>> agent can be found and the behavior turned off. >>> - Not always possible, as operator doesn't always have control over >>> non-DOIC agent as it might be in another operators network. Proposal >>> to address this through interop agreements but while this might work >>> in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >> Since you mentioned the 7068 requirements in the cons for option 1, >> it makes sense to mention them for others. This one misses on 6, but >> seems okay for 12 and 17. (I guess we should have had a requirement >> about not interfering with existing network features. If we had that, >> Option 2 would not comply.) >> >>> Option 3 Pros: >>> ------------ >>> - Does not require additional protocol machinery >>> - Gives operators the ability to keep features requiring origin-host >>> munging turned on while DOIC is rolled out. >> For very limited definitions of "rolled out." >> >>> Option 3 Cons: >>> ------------ >>> - Requires extra configuration (against requirement #6) >>> - Likely requires extra development in the reporting node that would >>> not otherwise be needed (ability to limit where overload reports are >>> sent) >>> - Not necessarily easy to determine in advance where which requests >>> will traverse a the non-DOIC agent >>> - Limits ability of operator to fully control overload >>> >> Seems to miss req 6 even worse than for option 2. Misses 17 in a >> similar way as option 1. Partially misses 34. >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Aug 18 18:42:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FACC1A877B for ; Mon, 18 Aug 2014 18:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QthtsCsfSfk for ; Mon, 18 Aug 2014 18:42:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B26B1A8778 for ; Mon, 18 Aug 2014 18:42:28 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7J1gPVL042572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2014 20:42:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53F277B9.1060509@usdonovans.com> Date: Mon, 18 Aug 2014 20:42:24 -0500 X-Mao-Original-Outgoing-Id: 430105344.648164-ffbd097e173c5f9584990595156d637c Content-Transfer-Encoding: quoted-printable Message-Id: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s2LjnIa4M0aQdCn5y6_Mw_Bkz6o Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 01:42:30 -0000 I support Alternative 1, but I'm not sure it's a complete solution. As Nirav pointed out, it has the potential to leak topology information = past a topology hiding proxy. (Unless we can come up with some = attribution scheme that is not based on Diameter Identity or IP = Address.) It may be reasonable, to do this, but we would need some = guidance to warn operators that this may happen if they enable DOIC = across a non-supporting, topology-hiding proxy. It would become the = operator's choice to decide which is more important. The part I find unsatisfying, is what would happen if you had some paths = that supported DOIC (or did not do topology hiding), and some paths that = don't support DOIC also do topology hiding. This could become a pretty = big administrative hit, and violates the spirit and letter of our = requirement to avoid adding lots of configuration work. OTOH, if we had a mechanism where servers could detect the existence of = a non-DOIC, topology-hiding proxy, this could be at least partially = automated. I can think of multiple ways we could make it possible to = tell if an immediate peer supports DOIC, but not so much for = non-adjacent nodes. On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: > All, >=20 > My recommendation on this alternative 1 as it give operators the = ability to discover when there is an issue associated with "Origin-Host = Munging" agents. The operators can then take any administrative action = necessary to fix the issue. It is also a more general solution that = does not rely on one industries interop procedures. >=20 > If we can get agreement on this then we can start making progress on = the remainder of the document. >=20 > Steve >=20 > On 8/12/14, 3:05 PM, Steve Donovan wrote: >> Are there other thoughts on the pros and cons of the three proposals = for resolution of issue #66? >>=20 >> Steve >>=20 >> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>=20 >>>> All, >>>>=20 >>>> The issue with pre-DOIC agents changing origin-host was been = discussed in this thread: >>>>=20 >>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>=20 >>>> One example of the impact of the issue is defined in this message: >>>>=20 >>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>=20 >>>> So far three solutions have been discussed for this issue: >>>>=20 >>>> 1) Attribution of overload reports. >>>> - Add diameter-id of the node that is overloaded into the OC-OLR = AVP. >>>> - Reacting node always uses the diameter-id in the OC-OLR report = when applying abatement algorithm logic. >>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there = is a difference, the reacting node should report on the condition = (event/alarm). Local policy would determine if the reacting node honors = the overload report or ignores the overload report. >>> I think the last entry is worth further discussion, but it's = probably more important to make a high level decision first. But, at = risk of getting ahead of myself: I have trouble imagining a situation = where honoring the overload report will be harmful, since if there is an = intervening OHMA, the reacting node will not likely have any host-routed = requests to the diameter-id from the OLR. OTOH, I have trouble imagining = where honoring the report would be useful, for the same reason. >>>=20 >>>> 2) Configuration in operator's networks to turn off origin-host = munging behavior until the agent is upgraded to support DOIC. >>>>=20 >>>> 3) Configuration of reporting nodes to not send overload reports, = either universally or for transactions that cross the origin-host = munging agent. >>>>=20 >>>> I've compiled a starting point for a pros and cons analysis of the = three approaches. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> --------- >>>>=20 >>>> Option 1 Pros: >>>> ------------ >>>> - Gives operators a mechanism to detect when there is a non-DOIC = origin-host-munging agent in the path of a transaction. >>>> - Gives operators ability to manage the under utilization issue = caused by the non-DOIC agent. >>>> - Gives operators the ability to keep features requiring = origin-host munging turned on while DOIC is rolled out. >>>> - Leaves the determination of which action to take in this scenario = (honor or ignore overload reports) to operator policy. >>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of = configuration required. >>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a = single node overload on the traffic handled by other nodes in the = network. >>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of = overload in a mixed DOIC environment on the overall capacity of the = network. >>> Specifically, it complies with the MUST NOT make things worth = clause, but does not comply with the SHOULD reduce overload clause. >>>=20 >>>> Option 1 Cons: >>>> ------------- >>>> - Requires additional protocol machinery (minimal) >>>> - Does not completely fix the effects of non-DOIC agent on overload = control >>> One additional con is that, if the OHMA is there for the purposes of = true topology hiding, the identity in the OLR may leak topology = information. >>>=20 >>>> Option 2 Pros: >>>> ------------ >>>> - Does not require additional protocol machinery >>>> - Does the best job of three alternatives in allowing for = management of overload conditions >>>>=20 >>>> Option 2 Cons: >>>> ------------ >>>> - Requires the operator to lose any functionality enabled by the = non-DOIC agent until all agents have been upgraded to support DOIC >>>> - Requires extra configuration (against requirement #6) >>>> - There is not way to determine if all non-DOIC origin-host munging = behavior has been turned off until an overload event happens, with = potential to have significant negative effects until the offending agent = can be found and the behavior turned off. >>>> - Not always possible, as operator doesn't always have control over = non-DOIC agent as it might be in another operators network. Proposal to = address this through interop agreements but while this might work in = 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>> Since you mentioned the 7068 requirements in the cons for option 1, = it makes sense to mention them for others. This one misses on 6, but = seems okay for 12 and 17. (I guess we should have had a requirement = about not interfering with existing network features. If we had that, = Option 2 would not comply.) >>>=20 >>>> Option 3 Pros: >>>> ------------ >>>> - Does not require additional protocol machinery >>>> - Gives operators the ability to keep features requiring = origin-host munging turned on while DOIC is rolled out. >>> For very limited definitions of "rolled out." >>>=20 >>>> Option 3 Cons: >>>> ------------ >>>> - Requires extra configuration (against requirement #6) >>>> - Likely requires extra development in the reporting node that = would not otherwise be needed (ability to limit where overload reports = are sent) >>>> - Not necessarily easy to determine in advance where which requests = will traverse a the non-DOIC agent >>>> - Limits ability of operator to fully control overload >>>>=20 >>> Seems to miss req 6 even worse than for option 2. Misses 17 in a = similar way as option 1. Partially misses 34. >>>=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 nobody Tue Aug 19 02:48:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799271A8881 for ; Tue, 19 Aug 2014 02:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfCh__-5OVo9 for ; Tue, 19 Aug 2014 02:48:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7E61A0368 for ; Tue, 19 Aug 2014 02:48:52 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 617AE1902AE; Tue, 19 Aug 2014 11:48:50 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 43248180051; Tue, 19 Aug 2014 11:48:47 +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.03.0195.001; Tue, 19 Aug 2014 11:48:47 +0200 From: To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPuy/+jVlWvNpVDk2Egm5b/cXi85vXBb8AgAClNPA= Date: Tue, 19 Aug 2014 09:48:46 +0000 Message-ID: <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.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: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.18.122119 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/i0sCggclrpmYkE8AKs8Bkqfqxhw Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 09:48:55 -0000 Because a a gent modifying the Origin-host can only be a proxy and a proxy = is by definition compliant with the application supporting the new OLR-rela= ted AVPs, everything else is out of scope of the standardization. Moreover,= the real added-value of the addition of the diameter-id in the OLR does no= t seem so clear. Finally, we have agreed that the basic mechanism proposed = in the draft may not cover all the use cases (existing or future) and can b= e enhanced if required, with or without the need for a IETF standard action. For all these reasons, I would recommend not to add this Diameter-id in the= OLR and to assume that the Origin-host is not changed by agent in the path= of the Diameter messages. Some extra text could also be added to clarify t= hat proxies modifying the Origin-host would have to be upgraded to manage c= onsistently the OLR received in Diameter application messages. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mardi 19 ao=FBt 2014 03:42 =C0=A0: Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is I support Alternative 1, but I'm not sure it's a complete solution. As Nirav pointed out, it has the potential to leak topology information pas= t a topology hiding proxy. (Unless we can come up with some attribution sch= eme that is not based on Diameter Identity or IP Address.) It may be reason= able, to do this, but we would need some guidance to warn operators that th= is may happen if they enable DOIC across a non-supporting, topology-hiding = proxy. It would become the operator's choice to decide which is more import= ant. The part I find unsatisfying, is what would happen if you had some paths th= at supported DOIC (or did not do topology hiding), and some paths that don'= t support DOIC also do topology hiding. This could become a pretty big admi= nistrative hit, and violates the spirit and letter of our requirement to av= oid adding lots of configuration work. OTOH, if we had a mechanism where servers could detect the existence of a n= on-DOIC, topology-hiding proxy, this could be at least partially automated.= I can think of multiple ways we could make it possible to tell if an immed= iate peer supports DOIC, but not so much for non-adjacent nodes. On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: > All, >=20 > My recommendation on this alternative 1 as it give operators the ability = to discover when there is an issue associated with "Origin-Host Munging" ag= ents. The operators can then take any administrative action necessary to f= ix the issue. It is also a more general solution that does not rely on one= industries interop procedures. >=20 > If we can get agreement on this then we can start making progress on the = remainder of the document. >=20 > Steve >=20 > On 8/12/14, 3:05 PM, Steve Donovan wrote: >> Are there other thoughts on the pros and cons of the three proposals for= resolution of issue #66? >>=20 >> Steve >>=20 >> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wr= ote: >>>=20 >>>> All, >>>>=20 >>>> The issue with pre-DOIC agents changing origin-host was been discussed= in this thread: >>>>=20 >>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>=20 >>>> One example of the impact of the issue is defined in this message: >>>>=20 >>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>=20 >>>> So far three solutions have been discussed for this issue: >>>>=20 >>>> 1) Attribution of overload reports. >>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>> - Reacting node always uses the diameter-id in the OC-OLR report when= applying abatement algorithm logic. >>>> - Reacting node detects when there is a difference between the diamet= er-id in the OC-OLR report and in the Origin-Host AVP. When there is a dif= ference, the reacting node should report on the condition (event/alarm). L= ocal policy would determine if the reacting node honors the overload report= or ignores the overload report. >>> I think the last entry is worth further discussion, but it's probably m= ore important to make a high level decision first. But, at risk of getting = ahead of myself: I have trouble imagining a situation where honoring the ov= erload report will be harmful, since if there is an intervening OHMA, the r= eacting node will not likely have any host-routed requests to the diameter-= id from the OLR. OTOH, I have trouble imagining where honoring the report w= ould be useful, for the same reason. >>>=20 >>>> 2) Configuration in operator's networks to turn off origin-host mungin= g behavior until the agent is upgraded to support DOIC. >>>>=20 >>>> 3) Configuration of reporting nodes to not send overload reports, eith= er universally or for transactions that cross the origin-host munging agent. >>>>=20 >>>> I've compiled a starting point for a pros and cons analysis of the thr= ee approaches. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> --------- >>>>=20 >>>> Option 1 Pros: >>>> ------------ >>>> - Gives operators a mechanism to detect when there is a non-DOIC origi= n-host-munging agent in the path of a transaction. >>>> - Gives operators ability to manage the under utilization issue caused= by the non-DOIC agent. >>>> - Gives operators the ability to keep features requiring origin-host m= unging turned on while DOIC is rolled out. >>>> - Leaves the determination of which action to take in this scenario (h= onor or ignore overload reports) to operator policy. >>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of config= uration required. >>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a sin= gle node overload on the traffic handled by other nodes in the network. >>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overl= oad in a mixed DOIC environment on the overall capacity of the network. >>> Specifically, it complies with the MUST NOT make things worth clause, b= ut does not comply with the SHOULD reduce overload clause. >>>=20 >>>> Option 1 Cons: >>>> ------------- >>>> - Requires additional protocol machinery (minimal) >>>> - Does not completely fix the effects of non-DOIC agent on overload co= ntrol >>> One additional con is that, if the OHMA is there for the purposes of tr= ue topology hiding, the identity in the OLR may leak topology information. >>>=20 >>>> Option 2 Pros: >>>> ------------ >>>> - Does not require additional protocol machinery >>>> - Does the best job of three alternatives in allowing for management o= f overload conditions >>>>=20 >>>> Option 2 Cons: >>>> ------------ >>>> - Requires the operator to lose any functionality enabled by the non-D= OIC agent until all agents have been upgraded to support DOIC >>>> - Requires extra configuration (against requirement #6) >>>> - There is not way to determine if all non-DOIC origin-host munging be= havior has been turned off until an overload event happens, with potential = to have significant negative effects until the offending agent can be found= and the behavior turned off. >>>> - Not always possible, as operator doesn't always have control over no= n-DOIC agent as it might be in another operators network. Proposal to addre= ss this through interop agreements but while this might work in 3GPP scenar= ios, not all Diameter deployments are 3GPP driven. >>> Since you mentioned the 7068 requirements in the cons for option 1, it = makes sense to mention them for others. This one misses on 6, but seems oka= y for 12 and 17. (I guess we should have had a requirement about not inter= fering with existing network features. If we had that, Option 2 would not c= omply.) >>>=20 >>>> Option 3 Pros: >>>> ------------ >>>> - Does not require additional protocol machinery >>>> - Gives operators the ability to keep features requiring origin-host m= unging turned on while DOIC is rolled out. >>> For very limited definitions of "rolled out." >>>=20 >>>> Option 3 Cons: >>>> ------------ >>>> - Requires extra configuration (against requirement #6) >>>> - Likely requires extra development in the reporting node that would n= ot otherwise be needed (ability to limit where overload reports are sent) >>>> - Not necessarily easy to determine in advance where which requests wi= ll traverse a the non-DOIC agent >>>> - Limits ability of operator to fully control overload >>>>=20 >>> Seems to miss req 6 even worse than for option 2. Misses 17 in a simila= r way as option 1. Partially misses 34. >>>=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 ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Aug 19 04:41:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863CD1A88C3 for ; Tue, 19 Aug 2014 04:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGb9o2yFiRvu for ; Tue, 19 Aug 2014 04:41:10 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FEA1A88C2 for ; Tue, 19 Aug 2014 04:41:09 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57806 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJhmj-0008Iy-El; Tue, 19 Aug 2014 04:41:08 -0700 Message-ID: <53F337D1.1070108@usdonovans.com> Date: Tue, 19 Aug 2014 06:41:05 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DTmUVvNuQvlNiickDaUUIns2ITs Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 11:41:12 -0000 Lionel, There are two primary reasons that I think option 1 is important: 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. More inline. Steve On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: > Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. SRD> I don't understand this argument. It is perfectly valid for a client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? > Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. SRD> See above. > Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. SRD> The reasons so far for deferring functionality was because it would add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. > > For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. > > Regards, > > Lionel > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoyé : mardi 19 août 2014 03:42 > À : Steve Donovan > Cc : dime@ietf.org > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > I support Alternative 1, but I'm not sure it's a complete solution. > > As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. > > The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. > > OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. > > On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: > >> All, >> >> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >> >> If we can get agreement on this then we can start making progress on the remainder of the document. >> >> Steve >> >> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>> >>> Steve >>> >>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>> >>>>> All, >>>>> >>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>> >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>> >>>>> One example of the impact of the issue is defined in this message: >>>>> >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>> >>>>> So far three solutions have been discussed for this issue: >>>>> >>>>> 1) Attribution of overload reports. >>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>> >>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>> >>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>> >>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> --------- >>>>> >>>>> Option 1 Pros: >>>>> ------------ >>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>> >>>>> Option 1 Cons: >>>>> ------------- >>>>> - Requires additional protocol machinery (minimal) >>>>> - Does not completely fix the effects of non-DOIC agent on overload control >>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>> >>>>> Option 2 Pros: >>>>> ------------ >>>>> - Does not require additional protocol machinery >>>>> - Does the best job of three alternatives in allowing for management of overload conditions >>>>> >>>>> Option 2 Cons: >>>>> ------------ >>>>> - Requires the operator to lose any functionality enabled by the non-DOIC agent until all agents have been upgraded to support DOIC >>>>> - Requires extra configuration (against requirement #6) >>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>> Since you mentioned the 7068 requirements in the cons for option 1, it makes sense to mention them for others. This one misses on 6, but seems okay for 12 and 17. (I guess we should have had a requirement about not interfering with existing network features. If we had that, Option 2 would not comply.) >>>> >>>>> Option 3 Pros: >>>>> ------------ >>>>> - Does not require additional protocol machinery >>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>> For very limited definitions of "rolled out." >>>> >>>>> Option 3 Cons: >>>>> ------------ >>>>> - Requires extra configuration (against requirement #6) >>>>> - Likely requires extra development in the reporting node that would not otherwise be needed (ability to limit where overload reports are sent) >>>>> - Not necessarily easy to determine in advance where which requests will traverse a the non-DOIC agent >>>>> - Limits ability of operator to fully control overload >>>>> >>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>> >>>> >>> _______________________________________________ >>> 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 > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Tue Aug 19 06:18:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF20C1A02D6 for ; Tue, 19 Aug 2014 06:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4dtjR-tElaN for ; Tue, 19 Aug 2014 06:18:07 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509F81A03F6 for ; Tue, 19 Aug 2014 06:18:07 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e8e43f35.0.4189052.00-2243.11713938.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 19 Aug 2014 13:18:07 +0000 (UTC) X-MXL-Hash: 53f34e8f4f024d48-a574d8ec9d86ab60485c7e9d5aee5f4b662e225b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s7JDI5lZ005826; Tue, 19 Aug 2014 09:18:06 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s7JDI3iO005797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2014 09:18:05 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 19 Aug 2014 13:17:54 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.133]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0195.001; Tue, 19 Aug 2014 09:17:54 -0400 From: "DOLLY, MARTIN C" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPuzAC3heh1tPl70eeXyFuwWaic5vX6Reg Date: Tue, 19 Aug 2014 13:17:53 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> In-Reply-To: <53F277B9.1060509@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.156.235] 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-AnalysisOut: [v=2.0 cv=b98FFK6x c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=k-axZJF5eAMA:10 a=-k7qv-lahOYA:10 a=ofMgfj31e3cA:10 a=6yX] X-AnalysisOut: [14QIomcIA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=yakATiurAAAA:8] X-AnalysisOut: [ a=nKlc45j9dxdE3zqwifEA:9 a=CjuIK1q_8ugA:10 a=VAerGHJrs0oA] X-AnalysisOut: [:10 a=oOOIGyV6YFoA:10 a=lZB815dzVvQA:10 a=BMZHtSBzE-QA:10 ] X-AnalysisOut: [a=2lIe7OUWHwoa9xiP:21 a=ECFIxixb-1TQticX:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5ffIzAQ59g2E2DEEgH5L76iNQU0 Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 13:18:10 -0000 Steve, I agree, this is worth protecting against. Regards, Martin=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Monday, August 18, 2014 6:01 PM To: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s All, My recommendation on this alternative 1 as it give operators the ability=20 to discover when there is an issue associated with "Origin-Host Munging"=20 agents. The operators can then take any administrative action necessary=20 to fix the issue. It is also a more general solution that does not rely=20 on one industries interop procedures. If we can get agreement on this then we can start making progress on the=20 remainder of the document. Steve On 8/12/14, 3:05 PM, Steve Donovan wrote: > Are there other thoughts on the pros and cons of the three proposals=20 > for resolution of issue #66? > > Steve > > On 8/8/14, 1:43 PM, Ben Campbell wrote: >> On Aug 8, 2014, at 9:48 AM, Steve Donovan =20 >> wrote: >> >>> All, >>> >>> The issue with pre-DOIC agents changing origin-host was been=20 >>> discussed in this thread: >>> >>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>> >>> One example of the impact of the issue is defined in this message: >>> >>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>> >>> So far three solutions have been discussed for this issue: >>> >>> 1) Attribution of overload reports. >>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>> - Reacting node always uses the diameter-id in the OC-OLR report=20 >>> when applying abatement algorithm logic. >>> - Reacting node detects when there is a difference between the=20 >>> diameter-id in the OC-OLR report and in the Origin-Host AVP. When=20 >>> there is a difference, the reacting node should report on the=20 >>> condition (event/alarm). Local policy would determine if the=20 >>> reacting node honors the overload report or ignores the overload=20 >>> report. >> I think the last entry is worth further discussion, but it's probably=20 >> more important to make a high level decision first. But, at risk of=20 >> getting ahead of myself: I have trouble imagining a situation where=20 >> honoring the overload report will be harmful, since if there is an=20 >> intervening OHMA, the reacting node will not likely have any=20 >> host-routed requests to the diameter-id from the OLR. OTOH, I have=20 >> trouble imagining where honoring the report would be useful, for the=20 >> same reason. >> >>> 2) Configuration in operator's networks to turn off origin-host=20 >>> munging behavior until the agent is upgraded to support DOIC. >>> >>> 3) Configuration of reporting nodes to not send overload reports,=20 >>> either universally or for transactions that cross the origin-host=20 >>> munging agent. >>> >>> I've compiled a starting point for a pros and cons analysis of the=20 >>> three approaches. >>> >>> Regards, >>> >>> Steve >>> >>> --------- >>> >>> Option 1 Pros: >>> ------------ >>> - Gives operators a mechanism to detect when there is a non-DOIC=20 >>> origin-host-munging agent in the path of a transaction. >>> - Gives operators ability to manage the under utilization issue=20 >>> caused by the non-DOIC agent. >>> - Gives operators the ability to keep features requiring origin-host=20 >>> munging turned on while DOIC is rolled out. >>> - Leaves the determination of which action to take in this scenario=20 >>> (honor or ignore overload reports) to operator policy. >>> - Addresses RFC 7068 requirement #6 on minimizing the amount of=20 >>> configuration required. >>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a=20 >>> single node overload on the traffic handled by other nodes in the=20 >>> network. >>> - Addresses RFC 7068 requirement #17 on minimizing the impact of=20 >>> overload in a mixed DOIC environment on the overall capacity of the=20 >>> network. >> Specifically, it complies with the MUST NOT make things worth clause,=20 >> but does not comply with the SHOULD reduce overload clause. >> >>> Option 1 Cons: >>> ------------- >>> - Requires additional protocol machinery (minimal) >>> - Does not completely fix the effects of non-DOIC agent on overload=20 >>> control >> One additional con is that, if the OHMA is there for the purposes of=20 >> true topology hiding, the identity in the OLR may leak topology=20 >> information. >> >>> Option 2 Pros: >>> ------------ >>> - Does not require additional protocol machinery >>> - Does the best job of three alternatives in allowing for management=20 >>> of overload conditions >>> >>> Option 2 Cons: >>> ------------ >>> - Requires the operator to lose any functionality enabled by the=20 >>> non-DOIC agent until all agents have been upgraded to support DOIC >>> - Requires extra configuration (against requirement #6) >>> - There is not way to determine if all non-DOIC origin-host munging=20 >>> behavior has been turned off until an overload event happens, with=20 >>> potential to have significant negative effects until the offending=20 >>> agent can be found and the behavior turned off. >>> - Not always possible, as operator doesn't always have control over=20 >>> non-DOIC agent as it might be in another operators network. Proposal=20 >>> to address this through interop agreements but while this might work=20 >>> in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >> Since you mentioned the 7068 requirements in the cons for option 1,=20 >> it makes sense to mention them for others. This one misses on 6, but=20 >> seems okay for 12 and 17. (I guess we should have had a requirement=20 >> about not interfering with existing network features. If we had that,=20 >> Option 2 would not comply.) >> >>> Option 3 Pros: >>> ------------ >>> - Does not require additional protocol machinery >>> - Gives operators the ability to keep features requiring origin-host=20 >>> munging turned on while DOIC is rolled out. >> For very limited definitions of "rolled out." >> >>> Option 3 Cons: >>> ------------ >>> - Requires extra configuration (against requirement #6) >>> - Likely requires extra development in the reporting node that would=20 >>> not otherwise be needed (ability to limit where overload reports are=20 >>> sent) >>> - Not necessarily easy to determine in advance where which requests=20 >>> will traverse a the non-DOIC agent >>> - Limits ability of operator to fully control overload >>> >> Seems to miss req 6 even worse than for option 2. Misses 17 in a=20 >> similar way as option 1. Partially misses 34. >> >> > > _______________________________________________ > 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 nobody Tue Aug 19 06:41:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A021A88F7 for ; Tue, 19 Aug 2014 06:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSJae904B-Dr for ; Tue, 19 Aug 2014 06:40:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAE41A88F4 for ; Tue, 19 Aug 2014 06:40:54 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EADDC3B423A; Tue, 19 Aug 2014 15:40:51 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id CACBE27C058; Tue, 19 Aug 2014 15:40:51 +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.03.0195.001; Tue, 19 Aug 2014 15:40:51 +0200 From: To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPuy/+jVlWvNpVDk2Egm5b/cXi85vXBb8AgAClNPCAAAIRgIAAPcnQ Date: Tue, 19 Aug 2014 13:40:51 +0000 Message-ID: <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> In-Reply-To: <53F337D1.1070108@usdonovans.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.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wVzjEge7w99KS7eWdWggHeE3gKI Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 13:41:04 -0000 Hi Steve, See below. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mardi 19 ao=FBt 2014 13:41 =C0=A0: MORAND Lionel IMT/OLN; Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is Lionel, There are two primary reasons that I think option 1 is important: 1) This scenario can result in significant under utilization of resources, = to the extreme of completely shutting down all traffic to the servers behin= d the Origin-Host Munging Agent (OHMA). 2) It gives operates a way to detect the unplanned or forgotten instance of= the OHMA. Being able to prevent number 1 is enough reason for me to add the very smal= l amount of additional protocol machinery we are talking about. [LM] And I disagree. More inline. [LM] same Steve On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: > Because a a gent modifying the Origin-host can only be a proxy and a prox= y is by definition compliant with the application supporting the new OLR-re= lated AVPs, everything else is out of scope of the standardization. SRD> I don't understand this argument. It is perfectly valid for a client or server to advertise support for an application and not also suppo= rt DOIC. Why do you imply that it would be different for an agent? [LM] A proxy that would modify the origin-host without taking into account = the possible use of this origin-host at the application would be a badly-de= signed proxy and should not be used in operational network. > Moreover, the real added-value of the addition of the diameter-id in the = OLR does not seem so clear. SRD> See above. [LM] still unclear > Finally, we have agreed that the basic mechanism proposed in the draft ma= y not cover all the use cases (existing or future) and can be enhanced if r= equired, with or without the need for a IETF standard action. SRD> The reasons so far for deferring functionality was because it would add risk to the schedule for finishing the core DOIC solution. That is not= the case here. We have a very small change to the specification that add= resses multiple requirements. [LM] is there any clear description of what will be the use of this info by= the reacting node? if the proxy replaces the origin-host A by origin-host = B, the Diameter nodes receiving the answers will "see" B as sender of the a= nswer and will use this id when sending new requests with origin-host AVP. = So can you remind me how exactly the reacting node will use the Diameter-id= received in the OLR? > > For all these reasons, I would recommend not to add this Diameter-id in t= he OLR and to assume that the Origin-host is not changed by agent in the pa= th of the Diameter messages. Some extra text could also be added to clarify= that proxies modifying the Origin-host would have to be upgraded to manage= consistently the OLR received in Diameter application messages. > > Regards, > > Lionel > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 > Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : dime@ietf.= org=20 > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives=20 > analysis > > I support Alternative 1, but I'm not sure it's a complete solution. > > As Nirav pointed out, it has the potential to leak topology information p= ast a topology hiding proxy. (Unless we can come up with some attribution s= cheme that is not based on Diameter Identity or IP Address.) It may be reas= onable, to do this, but we would need some guidance to warn operators that = this may happen if they enable DOIC across a non-supporting, topology-hidin= g proxy. It would become the operator's choice to decide which is more impo= rtant. > > The part I find unsatisfying, is what would happen if you had some paths = that supported DOIC (or did not do topology hiding), and some paths that do= n't support DOIC also do topology hiding. This could become a pretty big ad= ministrative hit, and violates the spirit and letter of our requirement to = avoid adding lots of configuration work. > > OTOH, if we had a mechanism where servers could detect the existence of a= non-DOIC, topology-hiding proxy, this could be at least partially automate= d. I can think of multiple ways we could make it possible to tell if an imm= ediate peer supports DOIC, but not so much for non-adjacent nodes. > > On Aug 18, 2014, at 5:01 PM, Steve Donovan wro= te: > >> All, >> >> My recommendation on this alternative 1 as it give operators the ability= to discover when there is an issue associated with "Origin-Host Munging" a= gents. The operators can then take any administrative action necessary to = fix the issue. It is also a more general solution that does not rely on on= e industries interop procedures. >> >> If we can get agreement on this then we can start making progress on the= remainder of the document. >> >> Steve >> >> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>> Are there other thoughts on the pros and cons of the three proposals fo= r resolution of issue #66? >>> >>> Steve >>> >>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan w= rote: >>>> >>>>> All, >>>>> >>>>> The issue with pre-DOIC agents changing origin-host was been discusse= d in this thread: >>>>> >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>> >>>>> One example of the impact of the issue is defined in this message: >>>>> >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>> >>>>> So far three solutions have been discussed for this issue: >>>>> >>>>> 1) Attribution of overload reports. >>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AV= P. >>>>> - Reacting node always uses the diameter-id in the OC-OLR report wh= en applying abatement algorithm logic. >>>>> - Reacting node detects when there is a difference between the diam= eter-id in the OC-OLR report and in the Origin-Host AVP. When there is a d= ifference, the reacting node should report on the condition (event/alarm). = Local policy would determine if the reacting node honors the overload repo= rt or ignores the overload report. >>>> I think the last entry is worth further discussion, but it's probably = more important to make a high level decision first. But, at risk of getting= ahead of myself: I have trouble imagining a situation where honoring the o= verload report will be harmful, since if there is an intervening OHMA, the = reacting node will not likely have any host-routed requests to the diameter= -id from the OLR. OTOH, I have trouble imagining where honoring the report = would be useful, for the same reason. >>>> >>>>> 2) Configuration in operator's networks to turn off origin-host mungi= ng behavior until the agent is upgraded to support DOIC. >>>>> >>>>> 3) Configuration of reporting nodes to not send overload reports, eit= her universally or for transactions that cross the origin-host munging agen= t. >>>>> >>>>> I've compiled a starting point for a pros and cons analysis of the th= ree approaches. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> --------- >>>>> >>>>> Option 1 Pros: >>>>> ------------ >>>>> - Gives operators a mechanism to detect when there is a non-DOIC orig= in-host-munging agent in the path of a transaction. >>>>> - Gives operators ability to manage the under utilization issue cause= d by the non-DOIC agent. >>>>> - Gives operators the ability to keep features requiring origin-host = munging turned on while DOIC is rolled out. >>>>> - Leaves the determination of which action to take in this scenario (= honor or ignore overload reports) to operator policy. >>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of confi= guration required. >>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a si= ngle node overload on the traffic handled by other nodes in the network. >>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of over= load in a mixed DOIC environment on the overall capacity of the network. >>>> Specifically, it complies with the MUST NOT make things worth clause, = but does not comply with the SHOULD reduce overload clause. >>>> >>>>> Option 1 Cons: >>>>> ------------- >>>>> - Requires additional protocol machinery (minimal) >>>>> - Does not completely fix the effects of non-DOIC agent on=20 >>>>> overload control >>>> One additional con is that, if the OHMA is there for the purposes of t= rue topology hiding, the identity in the OLR may leak topology information. >>>> >>>>> Option 2 Pros: >>>>> ------------ >>>>> - Does not require additional protocol machinery >>>>> - Does the best job of three alternatives in allowing for=20 >>>>> management of overload conditions >>>>> >>>>> Option 2 Cons: >>>>> ------------ >>>>> - Requires the operator to lose any functionality enabled by the=20 >>>>> non-DOIC agent until all agents have been upgraded to support DOIC >>>>> - Requires extra configuration (against requirement #6) >>>>> - There is not way to determine if all non-DOIC origin-host munging b= ehavior has been turned off until an overload event happens, with potential= to have significant negative effects until the offending agent can be foun= d and the behavior turned off. >>>>> - Not always possible, as operator doesn't always have control over n= on-DOIC agent as it might be in another operators network. Proposal to addr= ess this through interop agreements but while this might work in 3GPP scena= rios, not all Diameter deployments are 3GPP driven. >>>> Since you mentioned the 7068 requirements in the cons for option 1,=20 >>>> it makes sense to mention them for others. This one misses on 6,=20 >>>> but seems okay for 12 and 17. (I guess we should have had a=20 >>>> requirement about not interfering with existing network features.=20 >>>> If we had that, Option 2 would not comply.) >>>> >>>>> Option 3 Pros: >>>>> ------------ >>>>> - Does not require additional protocol machinery >>>>> - Gives operators the ability to keep features requiring origin-host = munging turned on while DOIC is rolled out. >>>> For very limited definitions of "rolled out." >>>> >>>>> Option 3 Cons: >>>>> ------------ >>>>> - Requires extra configuration (against requirement #6) >>>>> - Likely requires extra development in the reporting node that=20 >>>>> would not otherwise be needed (ability to limit where overload=20 >>>>> reports are sent) >>>>> - Not necessarily easy to determine in advance where which=20 >>>>> requests will traverse a the non-DOIC agent >>>>> - Limits ability of operator to fully control overload >>>>> >>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a simil= ar way as option 1. Partially misses 34. >>>> >>>> >>> _______________________________________________ >>> 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 > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Aug 19 07:45:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A181A042D for ; Tue, 19 Aug 2014 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0hZRj7f84bg for ; Tue, 19 Aug 2014 07:45:39 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F341A03C8 for ; Tue, 19 Aug 2014 07:45:39 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58351 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJkfF-0006Pu-7I; Tue, 19 Aug 2014 07:45:38 -0700 Message-ID: <53F3630C.5070104@usdonovans.com> Date: Tue, 19 Aug 2014 09:45:32 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ENEo-7qbmUrMUOuBcfNNuaGRBMI Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 14:45:42 -0000 Lionel, More inline. Steve On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: > Hi Steve, > > See below. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoyé : mardi 19 août 2014 13:41 > À : MORAND Lionel IMT/OLN; Ben Campbell > Cc : dime@ietf.org > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > Lionel, > > There are two primary reasons that I think option 1 is important: > > 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). > > 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. > > Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. > > [LM] And I disagree. > > More inline. > [LM] same > > Steve > > On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. > SRD> I don't understand this argument. It is perfectly valid for a > client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? > [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network. SRD2> Consider the following timeline: Date - Event: Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic. In 2011 this works perfectly well for all applications handled by the agent. Sometime in 2015 - The IETF publishes the DOIC specification. Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later? > >> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. > SRD> See above. > [LM] still unclear SRD2> Detection of the fact that an OHMA exists so that something intelligent can be done before it results in a total shutdown of the Diameter network. > >> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. > SRD> The reasons so far for deferring functionality was because it would > add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. > [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? SRD> Scroll down an look at the details behind alternative 1. > >> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : dime@ietf.org >> Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> I support Alternative 1, but I'm not sure it's a complete solution. >> >> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. >> >> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. >> >> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. >> >> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >> >>> All, >>> >>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >>> >>> If we can get agreement on this then we can start making progress on the remainder of the document. >>> >>> Steve >>> >>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>>> >>>> Steve >>>> >>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>> >>>>>> All, >>>>>> >>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>> >>>>>> One example of the impact of the issue is defined in this message: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>> >>>>>> So far three solutions have been discussed for this issue: >>>>>> >>>>>> 1) Attribution of overload reports. >>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>>> >>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>>> >>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>>> >>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> --------- >>>>>> >>>>>> Option 1 Pros: >>>>>> ------------ >>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>>> >>>>>> Option 1 Cons: >>>>>> ------------- >>>>>> - Requires additional protocol machinery (minimal) >>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>> overload control >>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>>> >>>>>> Option 2 Pros: >>>>>> ------------ >>>>>> - Does not require additional protocol machinery >>>>>> - Does the best job of three alternatives in allowing for >>>>>> management of overload conditions >>>>>> >>>>>> Option 2 Cons: >>>>>> ------------ >>>>>> - Requires the operator to lose any functionality enabled by the >>>>>> non-DOIC agent until all agents have been upgraded to support DOIC >>>>>> - Requires extra configuration (against requirement #6) >>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>> Since you mentioned the 7068 requirements in the cons for option 1, >>>>> it makes sense to mention them for others. This one misses on 6, >>>>> but seems okay for 12 and 17. (I guess we should have had a >>>>> requirement about not interfering with existing network features. >>>>> If we had that, Option 2 would not comply.) >>>>> >>>>>> Option 3 Pros: >>>>>> ------------ >>>>>> - Does not require additional protocol machinery >>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>> For very limited definitions of "rolled out." >>>>> >>>>>> Option 3 Cons: >>>>>> ------------ >>>>>> - Requires extra configuration (against requirement #6) >>>>>> - Likely requires extra development in the reporting node that >>>>>> would not otherwise be needed (ability to limit where overload >>>>>> reports are sent) >>>>>> - Not necessarily easy to determine in advance where which >>>>>> requests will traverse a the non-DOIC agent >>>>>> - Limits ability of operator to fully control overload >>>>>> >>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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. >> >> > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Tue Aug 19 08:27:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A701A045D for ; Tue, 19 Aug 2014 08:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ7gy1gFFoha for ; Tue, 19 Aug 2014 08:27:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3341A0390 for ; Tue, 19 Aug 2014 08:27:22 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 0478237408F; Tue, 19 Aug 2014 17:27:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id CFBBA38406E; Tue, 19 Aug 2014 17:26:59 +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.03.0195.001; Tue, 19 Aug 2014 17:26:59 +0200 From: To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPu7xAixeXE7DuBE6VeIfag6SAwpvYCiZw Date: Tue, 19 Aug 2014 15:26:59 +0000 Message-ID: <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> In-Reply-To: <53F3630C.5070104@usdonovans.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.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.220919 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1KHoSrgnKoBzVXq8dA4Vxo_SOtc Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 15:27:28 -0000 Hi Steve, If you decide to deploy a proxy modifying the origin-host, it would be for = some specific purposes in a given context. If the context has changed, you = will have to reconsider the whole mechanism. And it is not only related to = DOIC. If not done, this is what I'm calling a bad design: it is not only about th= e implementation of the product itself, it is also about how this product i= s used in the operational network. And I don't buy the argument that an operator might have forgotten that a p= roxy modifying origin-host would have been deployed in the network before t= he introduction of DOIC. About alt 1: >>>>>> 1) Attribution of overload reports. >>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR = AVP. >>>>>> - Reacting node always uses the diameter-id in the OC-OLR report = when applying abatement algorithm logic. >>>>>> - Reacting node detects when there is a difference between the di= ameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a= difference, the reacting node should report on the condition (event/alarm)= . Local policy would determine if the reacting node honors the overload re= port or ignores the overload report. The following question still remain not answered: if the proxy replaces the= origin-host A by origin-host B, the Diameter nodes receiving the answers w= ill "see" B as sender of the answer and will use this id when sending new r= equests with origin-host AVP. So can you remind me how exactly the reacting= node will use the Diameter-id received in the OLR? Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mardi 19 ao=FBt 2014 16:46 =C0=A0: MORAND Lionel IMT/OLN; Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is Lionel, More inline. Steve On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: > Hi Steve, > > See below. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 19= =20 > ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc :=20 > dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 > alternatives analysis > > Lionel, > > There are two primary reasons that I think option 1 is important: > > 1) This scenario can result in significant under utilization of resources= , to the extreme of completely shutting down all traffic to the servers beh= ind the Origin-Host Munging Agent (OHMA). > > 2) It gives operates a way to detect the unplanned or forgotten instance = of the OHMA. > > Being able to prevent number 1 is enough reason for me to add the very sm= all amount of additional protocol machinery we are talking about. > > [LM] And I disagree. > > More inline. > [LM] same > > Steve > > On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >> Because a a gent modifying the Origin-host can only be a proxy and a pro= xy is by definition compliant with the application supporting the new OLR-r= elated AVPs, everything else is out of scope of the standardization. > SRD> I don't understand this argument. It is perfectly valid for a > client or server to advertise support for an application and not also sup= port DOIC. Why do you imply that it would be different for an agent? > [LM] A proxy that would modify the origin-host without taking into accoun= t the possible use of this origin-host at the application would be a badly-= designed proxy and should not be used in operational network. SRD2> Consider the following timeline: Date - Event: Sometime in 2011 - Operator installs an agent to do topology hiding or load= balancing or some other function and the agent modifies the origin-host AV= P as part of its logic. In 2011 this works perfectly well for all applicat= ions handled by the agent. Sometime in 2015 - The IETF publishes the DOIC specification. Are you asserting that the agent deployed in 2011 was badly designed becaus= e it did not anticipate the DOIC solution published four years later? > >> Moreover, the real added-value of the addition of the diameter-id in the= OLR does not seem so clear. > SRD> See above. > [LM] still unclear SRD2> Detection of the fact that an OHMA exists so that something intelligent can be done before it results in a total shutdown of the Diamet= er network. > >> Finally, we have agreed that the basic mechanism proposed in the draft m= ay not cover all the use cases (existing or future) and can be enhanced if = required, with or without the need for a IETF standard action. > SRD> The reasons so far for deferring functionality was because it=20 > SRD> would > add risk to the schedule for finishing the core DOIC solution. That is n= ot the case here. We have a very small change to the specification that a= ddresses multiple requirements. > [LM] is there any clear description of what will be the use of this info = by the reacting node? if the proxy replaces the origin-host A by origin-hos= t B, the Diameter nodes receiving the answers will "see" B as sender of the= answer and will use this id when sending new requests with origin-host AVP= . So can you remind me how exactly the reacting node will use the Diameter-= id received in the OLR? SRD> Scroll down an look at the details behind alternative 1. > >> For all these reasons, I would recommend not to add this Diameter-id in = the OLR and to assume that the Origin-host is not changed by agent in the p= ath of the Diameter messages. Some extra text could also be added to clarif= y that proxies modifying the Origin-host would have to be upgraded to manag= e consistently the OLR received in Diameter application messages. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 >> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc :=20 >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >> alternatives analysis >> >> I support Alternative 1, but I'm not sure it's a complete solution. >> >> As Nirav pointed out, it has the potential to leak topology information = past a topology hiding proxy. (Unless we can come up with some attribution = scheme that is not based on Diameter Identity or IP Address.) It may be rea= sonable, to do this, but we would need some guidance to warn operators that= this may happen if they enable DOIC across a non-supporting, topology-hidi= ng proxy. It would become the operator's choice to decide which is more imp= ortant. >> >> The part I find unsatisfying, is what would happen if you had some paths= that supported DOIC (or did not do topology hiding), and some paths that d= on't support DOIC also do topology hiding. This could become a pretty big a= dministrative hit, and violates the spirit and letter of our requirement to= avoid adding lots of configuration work. >> >> OTOH, if we had a mechanism where servers could detect the existence of = a non-DOIC, topology-hiding proxy, this could be at least partially automat= ed. I can think of multiple ways we could make it possible to tell if an im= mediate peer supports DOIC, but not so much for non-adjacent nodes. >> >> On Aug 18, 2014, at 5:01 PM, Steve Donovan wr= ote: >> >>> All, >>> >>> My recommendation on this alternative 1 as it give operators the abilit= y to discover when there is an issue associated with "Origin-Host Munging" = agents. The operators can then take any administrative action necessary to= fix the issue. It is also a more general solution that does not rely on o= ne industries interop procedures. >>> >>> If we can get agreement on this then we can start making progress on th= e remainder of the document. >>> >>> Steve >>> >>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>> Are there other thoughts on the pros and cons of the three proposals f= or resolution of issue #66? >>>> >>>> Steve >>>> >>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>>> >>>>>> All, >>>>>> >>>>>> The issue with pre-DOIC agents changing origin-host was been discuss= ed in this thread: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>> >>>>>> One example of the impact of the issue is defined in this message: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>> >>>>>> So far three solutions have been discussed for this issue: >>>>>> >>>>>> 1) Attribution of overload reports. >>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR = AVP. >>>>>> - Reacting node always uses the diameter-id in the OC-OLR report = when applying abatement algorithm logic. >>>>>> - Reacting node detects when there is a difference between the di= ameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a= difference, the reacting node should report on the condition (event/alarm)= . Local policy would determine if the reacting node honors the overload re= port or ignores the overload report. >>>>> I think the last entry is worth further discussion, but it's probably= more important to make a high level decision first. But, at risk of gettin= g ahead of myself: I have trouble imagining a situation where honoring the = overload report will be harmful, since if there is an intervening OHMA, the= reacting node will not likely have any host-routed requests to the diamete= r-id from the OLR. OTOH, I have trouble imagining where honoring the report= would be useful, for the same reason. >>>>> >>>>>> 2) Configuration in operator's networks to turn off origin-host mung= ing behavior until the agent is upgraded to support DOIC. >>>>>> >>>>>> 3) Configuration of reporting nodes to not send overload reports, ei= ther universally or for transactions that cross the origin-host munging age= nt. >>>>>> >>>>>> I've compiled a starting point for a pros and cons analysis of the t= hree approaches. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> --------- >>>>>> >>>>>> Option 1 Pros: >>>>>> ------------ >>>>>> - Gives operators a mechanism to detect when there is a non-DOIC ori= gin-host-munging agent in the path of a transaction. >>>>>> - Gives operators ability to manage the under utilization issue caus= ed by the non-DOIC agent. >>>>>> - Gives operators the ability to keep features requiring origin-host= munging turned on while DOIC is rolled out. >>>>>> - Leaves the determination of which action to take in this scenario = (honor or ignore overload reports) to operator policy. >>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of conf= iguration required. >>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a s= ingle node overload on the traffic handled by other nodes in the network. >>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of ove= rload in a mixed DOIC environment on the overall capacity of the network. >>>>> Specifically, it complies with the MUST NOT make things worth clause,= but does not comply with the SHOULD reduce overload clause. >>>>> >>>>>> Option 1 Cons: >>>>>> ------------- >>>>>> - Requires additional protocol machinery (minimal) >>>>>> - Does not completely fix the effects of non-DOIC agent on=20 >>>>>> overload control >>>>> One additional con is that, if the OHMA is there for the purposes of = true topology hiding, the identity in the OLR may leak topology information. >>>>> >>>>>> Option 2 Pros: >>>>>> ------------ >>>>>> - Does not require additional protocol machinery >>>>>> - Does the best job of three alternatives in allowing for=20 >>>>>> management of overload conditions >>>>>> >>>>>> Option 2 Cons: >>>>>> ------------ >>>>>> - Requires the operator to lose any functionality enabled by the=20 >>>>>> non-DOIC agent until all agents have been upgraded to support=20 >>>>>> DOIC >>>>>> - Requires extra configuration (against requirement #6) >>>>>> - There is not way to determine if all non-DOIC origin-host munging = behavior has been turned off until an overload event happens, with potentia= l to have significant negative effects until the offending agent can be fou= nd and the behavior turned off. >>>>>> - Not always possible, as operator doesn't always have control over = non-DOIC agent as it might be in another operators network. Proposal to add= ress this through interop agreements but while this might work in 3GPP scen= arios, not all Diameter deployments are 3GPP driven. >>>>> Since you mentioned the 7068 requirements in the cons for option=20 >>>>> 1, it makes sense to mention them for others. This one misses on=20 >>>>> 6, but seems okay for 12 and 17. (I guess we should have had a=20 >>>>> requirement about not interfering with existing network features. >>>>> If we had that, Option 2 would not comply.) >>>>> >>>>>> Option 3 Pros: >>>>>> ------------ >>>>>> - Does not require additional protocol machinery >>>>>> - Gives operators the ability to keep features requiring origin-host= munging turned on while DOIC is rolled out. >>>>> For very limited definitions of "rolled out." >>>>> >>>>>> Option 3 Cons: >>>>>> ------------ >>>>>> - Requires extra configuration (against requirement #6) >>>>>> - Likely requires extra development in the reporting node that=20 >>>>>> would not otherwise be needed (ability to limit where overload=20 >>>>>> reports are sent) >>>>>> - Not necessarily easy to determine in advance where which=20 >>>>>> requests will traverse a the non-DOIC agent >>>>>> - Limits ability of operator to fully control overload >>>>>> >>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a simi= lar way as option 1. Partially misses 34. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Aug 19 08:46:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2B1A04B4 for ; Tue, 19 Aug 2014 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JazKf9XAcnzu for ; Tue, 19 Aug 2014 08:46:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE021A04A9 for ; Tue, 19 Aug 2014 08:46:53 -0700 (PDT) Received: from [108.62.214.248] (port=58618 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJlcY-0006BX-HP; Tue, 19 Aug 2014 08:46:52 -0700 Message-ID: <53F3716A.5020003@usdonovans.com> Date: Tue, 19 Aug 2014 10:46:50 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6ZS0xzWqMxkmzzZ6wM9kz0u9gkA Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 15:46:56 -0000 On 8/19/14, 10:26 AM, lionel.morand@orange.com wrote: > Hi Steve, > > If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC. > If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network. > And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC. SRD> The agent does not need to be in the "home" operators network for the problem to exist. > > About alt 1: > >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. > The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? SRD> See the third sub-bullet: 1) Attribution of overload reports. - Add diameter-id of the node that is overloaded into the OC-OLR AVP. - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoyé : mardi 19 août 2014 16:46 > À : MORAND Lionel IMT/OLN; Ben Campbell > Cc : dime@ietf.org > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > Lionel, > > More inline. > > Steve > > On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> See below. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi 19 >> août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >> alternatives analysis >> >> Lionel, >> >> There are two primary reasons that I think option 1 is important: >> >> 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). >> >> 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. >> >> Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. >> >> [LM] And I disagree. >> >> More inline. >> [LM] same >> >> Steve >> >> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. >> SRD> I don't understand this argument. It is perfectly valid for a >> client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? >> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network. > SRD2> Consider the following timeline: > > Date - Event: > > Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic. In 2011 this works perfectly well for all applications handled by the agent. > > Sometime in 2015 - The IETF publishes the DOIC specification. > > Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later? >>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. >> SRD> See above. >> [LM] still unclear > SRD2> Detection of the fact that an OHMA exists so that something > intelligent can be done before it results in a total shutdown of the Diameter network. >>> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. >> SRD> The reasons so far for deferring functionality was because it >> SRD> would >> add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. >> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? > SRD> Scroll down an look at the details behind alternative 1. >>> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> I support Alternative 1, but I'm not sure it's a complete solution. >>> >>> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. >>> >>> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. >>> >>> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. >>> >>> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >>> >>>> All, >>>> >>>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >>>> >>>> If we can get agreement on this then we can start making progress on the remainder of the document. >>>> >>>> Steve >>>> >>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>>>> >>>>> Steve >>>>> >>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>> >>>>>>> One example of the impact of the issue is defined in this message: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>> >>>>>>> So far three solutions have been discussed for this issue: >>>>>>> >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>>>> >>>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>>>> >>>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>>>> >>>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Option 1 Pros: >>>>>>> ------------ >>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>>>> >>>>>>> Option 1 Cons: >>>>>>> ------------- >>>>>>> - Requires additional protocol machinery (minimal) >>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>> overload control >>>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>>>> >>>>>>> Option 2 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Does the best job of three alternatives in allowing for >>>>>>> management of overload conditions >>>>>>> >>>>>>> Option 2 Cons: >>>>>>> ------------ >>>>>>> - Requires the operator to lose any functionality enabled by the >>>>>>> non-DOIC agent until all agents have been upgraded to support >>>>>>> DOIC >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>> requirement about not interfering with existing network features. >>>>>> If we had that, Option 2 would not comply.) >>>>>> >>>>>>> Option 3 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>> For very limited definitions of "rolled out." >>>>>> >>>>>>> Option 3 Cons: >>>>>>> ------------ >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - Likely requires extra development in the reporting node that >>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>> reports are sent) >>>>>>> - Not necessarily easy to determine in advance where which >>>>>>> requests will traverse a the non-DOIC agent >>>>>>> - Limits ability of operator to fully control overload >>>>>>> >>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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. >>> >>> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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. >> >> > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Tue Aug 19 09:16:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03411A05E5 for ; Tue, 19 Aug 2014 09:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ie_YWw09fhY for ; Tue, 19 Aug 2014 09:16:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A455C1A0642 for ; Tue, 19 Aug 2014 09:16:30 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 086933B4125; Tue, 19 Aug 2014 18:16:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id DF9AE384072; Tue, 19 Aug 2014 18:16:28 +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.03.0195.001; Tue, 19 Aug 2014 18:16:28 +0200 From: To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPu7xAixeXE7DuBE6VeIfag6SAwpvYCiZw///mbwCAACO2cA== Date: Tue, 19 Aug 2014 16:16:27 +0000 Message-ID: <28364_1408464988_53F3785C_28364_11107_1_6B7134B31289DC4FAF731D844122B36E6BC9DF@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3716A.5020003@usdonovans.com> In-Reply-To: <53F3716A.5020003@usdonovans.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.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.19.100023 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3Oa4bPiVz7E6FGwZOksOrws9-OQ Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 16:16:34 -0000 Hi Steve, Please see below. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mardi 19 ao=FBt 2014 17:47 =C0=A0: MORAND Lionel IMT/OLN; Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is On 8/19/14, 10:26 AM, lionel.morand@orange.com wrote: > Hi Steve, > > If you decide to deploy a proxy modifying the origin-host, it would be fo= r some specific purposes in a given context. If the context has changed, yo= u will have to reconsider the whole mechanism. And it is not only related t= o DOIC. > If not done, this is what I'm calling a bad design: it is not only about = the implementation of the product itself, it is also about how this product= is used in the operational network. > And I don't buy the argument that an operator might have forgotten that a= proxy modifying origin-host would have been deployed in the network before= the introduction of DOIC. SRD> The agent does not need to be in the "home" operators network for the problem to exist. [LM] it is even worst from my point of view. How do you route requests with= origin-host initiated by a client in the visited domain towards the home n= etwork? > > About alt 1: > >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OL= R AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR repor= t when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is= a difference, the reacting node should report on the condition (event/alar= m). Local policy would determine if the reacting node honors the overload = report or ignores the overload report. > The following question still remain not answered: if the proxy replaces t= he origin-host A by origin-host B, the Diameter nodes receiving the answers= will "see" B as sender of the answer and will use this id when sending new= requests with origin-host AVP. So can you remind me how exactly the reacti= ng node will use the Diameter-id received in the OLR? SRD> See the third sub-bullet: 1) Attribution of overload reports. - Add diameter-id of the node that is overloaded into the OC-OLR AVP. - Reacting node always uses the diameter-id in the OC-OLR report when ap= plying abatement algorithm logic. - Reacting node detects when there is a difference between the diameter-= id in the OC-OLR report and in the Origin-Host AVP. When there is a differ= ence, the reacting node should report on the condition (event/alarm). Loca= l policy would determine if the reacting node honors the overload report or= ignores the overload report. [LM] the second bullet should be read as follow: Reacting node always uses = the diameter-id in the OC-OLR report when applying abatement algorithm logi= c to requests sent with origin-host. Right?=20 > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 19= =20 > ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc :=20 > dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 > alternatives analysis > > Lionel, > > More inline. > > Steve > > On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> See below. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi=20 >> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >> alternatives analysis >> >> Lionel, >> >> There are two primary reasons that I think option 1 is important: >> >> 1) This scenario can result in significant under utilization of resource= s, to the extreme of completely shutting down all traffic to the servers be= hind the Origin-Host Munging Agent (OHMA). >> >> 2) It gives operates a way to detect the unplanned or forgotten instance= of the OHMA. >> >> Being able to prevent number 1 is enough reason for me to add the very s= mall amount of additional protocol machinery we are talking about. >> >> [LM] And I disagree. >> >> More inline. >> [LM] same >> >> Steve >> >> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>> Because a a gent modifying the Origin-host can only be a proxy and a pr= oxy is by definition compliant with the application supporting the new OLR-= related AVPs, everything else is out of scope of the standardization. >> SRD> I don't understand this argument. It is perfectly valid for a >> client or server to advertise support for an application and not also su= pport DOIC. Why do you imply that it would be different for an agent? >> [LM] A proxy that would modify the origin-host without taking into accou= nt the possible use of this origin-host at the application would be a badly= -designed proxy and should not be used in operational network. > SRD2> Consider the following timeline: > > Date - Event: > > Sometime in 2011 - Operator installs an agent to do topology hiding or lo= ad balancing or some other function and the agent modifies the origin-host = AVP as part of its logic. In 2011 this works perfectly well for all applic= ations handled by the agent. > > Sometime in 2015 - The IETF publishes the DOIC specification. > > Are you asserting that the agent deployed in 2011 was badly designed beca= use it did not anticipate the DOIC solution published four years later? >>> Moreover, the real added-value of the addition of the diameter-id in th= e OLR does not seem so clear. >> SRD> See above. >> [LM] still unclear > SRD2> Detection of the fact that an OHMA exists so that something > intelligent can be done before it results in a total shutdown of the Diam= eter network. >>> Finally, we have agreed that the basic mechanism proposed in the draft = may not cover all the use cases (existing or future) and can be enhanced if= required, with or without the need for a IETF standard action. >> SRD> The reasons so far for deferring functionality was because it=20 >> SRD> would >> add risk to the schedule for finishing the core DOIC solution. That is = not the case here. We have a very small change to the specification that = addresses multiple requirements. >> [LM] is there any clear description of what will be the use of this info= by the reacting node? if the proxy replaces the origin-host A by origin-ho= st B, the Diameter nodes receiving the answers will "see" B as sender of th= e answer and will use this id when sending new requests with origin-host AV= P. So can you remind me how exactly the reacting node will use the Diameter= -id received in the OLR? > SRD> Scroll down an look at the details behind alternative 1. >>> For all these reasons, I would recommend not to add this Diameter-id in= the OLR and to assume that the Origin-host is not changed by agent in the = path of the Diameter messages. Some extra text could also be added to clari= fy that proxies modifying the Origin-host would have to be upgraded to mana= ge consistently the OLR received in Diameter application messages. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 >>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >>> alternatives analysis >>> >>> I support Alternative 1, but I'm not sure it's a complete solution. >>> >>> As Nirav pointed out, it has the potential to leak topology information= past a topology hiding proxy. (Unless we can come up with some attribution= scheme that is not based on Diameter Identity or IP Address.) It may be re= asonable, to do this, but we would need some guidance to warn operators tha= t this may happen if they enable DOIC across a non-supporting, topology-hid= ing proxy. It would become the operator's choice to decide which is more im= portant. >>> >>> The part I find unsatisfying, is what would happen if you had some path= s that supported DOIC (or did not do topology hiding), and some paths that = don't support DOIC also do topology hiding. This could become a pretty big = administrative hit, and violates the spirit and letter of our requirement t= o avoid adding lots of configuration work. >>> >>> OTOH, if we had a mechanism where servers could detect the existence of= a non-DOIC, topology-hiding proxy, this could be at least partially automa= ted. I can think of multiple ways we could make it possible to tell if an i= mmediate peer supports DOIC, but not so much for non-adjacent nodes. >>> >>> On Aug 18, 2014, at 5:01 PM, Steve Donovan w= rote: >>> >>>> All, >>>> >>>> My recommendation on this alternative 1 as it give operators the abili= ty to discover when there is an issue associated with "Origin-Host Munging"= agents. The operators can then take any administrative action necessary t= o fix the issue. It is also a more general solution that does not rely on = one industries interop procedures. >>>> >>>> If we can get agreement on this then we can start making progress on t= he remainder of the document. >>>> >>>> Steve >>>> >>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>> Are there other thoughts on the pros and cons of the three proposals = for resolution of issue #66? >>>>> >>>>> Steve >>>>> >>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> The issue with pre-DOIC agents changing origin-host was been discus= sed in this thread: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>> >>>>>>> One example of the impact of the issue is defined in this message: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>> >>>>>>> So far three solutions have been discussed for this issue: >>>>>>> >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OL= R AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR repor= t when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is= a difference, the reacting node should report on the condition (event/alar= m). Local policy would determine if the reacting node honors the overload = report or ignores the overload report. >>>>>> I think the last entry is worth further discussion, but it's probabl= y more important to make a high level decision first. But, at risk of getti= ng ahead of myself: I have trouble imagining a situation where honoring the= overload report will be harmful, since if there is an intervening OHMA, th= e reacting node will not likely have any host-routed requests to the diamet= er-id from the OLR. OTOH, I have trouble imagining where honoring the repor= t would be useful, for the same reason. >>>>>> >>>>>>> 2) Configuration in operator's networks to turn off origin-host mun= ging behavior until the agent is upgraded to support DOIC. >>>>>>> >>>>>>> 3) Configuration of reporting nodes to not send overload reports, e= ither universally or for transactions that cross the origin-host munging ag= ent. >>>>>>> >>>>>>> I've compiled a starting point for a pros and cons analysis of the = three approaches. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Option 1 Pros: >>>>>>> ------------ >>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC or= igin-host-munging agent in the path of a transaction. >>>>>>> - Gives operators ability to manage the under utilization issue cau= sed by the non-DOIC agent. >>>>>>> - Gives operators the ability to keep features requiring origin-hos= t munging turned on while DOIC is rolled out. >>>>>>> - Leaves the determination of which action to take in this scenario= (honor or ignore overload reports) to operator policy. >>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of con= figuration required. >>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a = single node overload on the traffic handled by other nodes in the network. >>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of ov= erload in a mixed DOIC environment on the overall capacity of the network. >>>>>> Specifically, it complies with the MUST NOT make things worth clause= , but does not comply with the SHOULD reduce overload clause. >>>>>> >>>>>>> Option 1 Cons: >>>>>>> ------------- >>>>>>> - Requires additional protocol machinery (minimal) >>>>>>> - Does not completely fix the effects of non-DOIC agent on=20 >>>>>>> overload control >>>>>> One additional con is that, if the OHMA is there for the purposes of= true topology hiding, the identity in the OLR may leak topology informatio= n. >>>>>> >>>>>>> Option 2 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Does the best job of three alternatives in allowing for=20 >>>>>>> management of overload conditions >>>>>>> >>>>>>> Option 2 Cons: >>>>>>> ------------ >>>>>>> - Requires the operator to lose any functionality enabled by the=20 >>>>>>> non-DOIC agent until all agents have been upgraded to support=20 >>>>>>> DOIC >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - There is not way to determine if all non-DOIC origin-host munging= behavior has been turned off until an overload event happens, with potenti= al to have significant negative effects until the offending agent can be fo= und and the behavior turned off. >>>>>>> - Not always possible, as operator doesn't always have control over= non-DOIC agent as it might be in another operators network. Proposal to ad= dress this through interop agreements but while this might work in 3GPP sce= narios, not all Diameter deployments are 3GPP driven. >>>>>> Since you mentioned the 7068 requirements in the cons for option=20 >>>>>> 1, it makes sense to mention them for others. This one misses on=20 >>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a=20 >>>>>> requirement about not interfering with existing network features. >>>>>> If we had that, Option 2 would not comply.) >>>>>> >>>>>>> Option 3 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Gives operators the ability to keep features requiring origin-hos= t munging turned on while DOIC is rolled out. >>>>>> For very limited definitions of "rolled out." >>>>>> >>>>>>> Option 3 Cons: >>>>>>> ------------ >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - Likely requires extra development in the reporting node that=20 >>>>>>> would not otherwise be needed (ability to limit where overload=20 >>>>>>> reports are sent) >>>>>>> - Not necessarily easy to determine in advance where which=20 >>>>>>> requests will traverse a the non-DOIC agent >>>>>>> - Limits ability of operator to fully control overload >>>>>>> >>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a sim= ilar way as option 1. Partially misses 34. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Aug 19 09:57:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3F1A064F for ; Tue, 19 Aug 2014 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0TwGC89XyzH for ; Tue, 19 Aug 2014 09:57:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04541A0640 for ; Tue, 19 Aug 2014 09:57:21 -0700 (PDT) Received: from [108.62.214.251] (port=59005 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJmig-0002n9-S9; Tue, 19 Aug 2014 09:57:20 -0700 Message-ID: <53F381EA.4050603@usdonovans.com> Date: Tue, 19 Aug 2014 11:57:14 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3716A.5020003@usdonovans.com> <28364_1408464988_53F3785C_28364_11107_1_6B7134B31289DC4FAF731D844122B36E6BC9DF@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <28364_1408464988_53F3785C_28364_11107_1_6B7134B31289DC4FAF731D844122B36E6BC9DF@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6UVufcWCL-YH33EAhO0-YPR0UEg Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 16:57:28 -0000 On 8/19/14, 11:16 AM, lionel.morand@orange.com wrote: > Hi Steve, > > Please see below. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoyé : mardi 19 août 2014 17:47 > À : MORAND Lionel IMT/OLN; Ben Campbell > Cc : dime@ietf.org > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > > On 8/19/14, 10:26 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC. >> If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network. >> And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC. > SRD> The agent does not need to be in the "home" operators network for > the problem to exist. > > [LM] it is even worst from my point of view. How do you route requests with origin-host initiated by a client in the visited domain towards the home network? SRD2> That would presumably be up to the visited networks routing policy but most likely based on the realm. > >> About alt 1: >> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >> The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? > SRD> See the third sub-bullet: > > 1) Attribution of overload reports. > - Add diameter-id of the node that is overloaded into the OC-OLR AVP. > - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. > - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. > > [LM] the second bullet should be read as follow: Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic to requests sent with origin-host. Right? SRD> Yes. > >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi 19 >> août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >> alternatives analysis >> >> Lionel, >> >> More inline. >> >> Steve >> >> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> See below. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi >>> 19 août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> There are two primary reasons that I think option 1 is important: >>> >>> 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). >>> >>> 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. >>> >>> Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. >>> >>> [LM] And I disagree. >>> >>> More inline. >>> [LM] same >>> >>> Steve >>> >>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. >>> SRD> I don't understand this argument. It is perfectly valid for a >>> client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? >>> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network. >> SRD2> Consider the following timeline: >> >> Date - Event: >> >> Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic. In 2011 this works perfectly well for all applications handled by the agent. >> >> Sometime in 2015 - The IETF publishes the DOIC specification. >> >> Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later? >>>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. >>> SRD> See above. >>> [LM] still unclear >> SRD2> Detection of the fact that an OHMA exists so that something >> intelligent can be done before it results in a total shutdown of the Diameter network. >>>> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. >>> SRD> The reasons so far for deferring functionality was because it >>> SRD> would >>> add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. >>> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? >> SRD> Scroll down an look at the details behind alternative 1. >>>> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>> >>>> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. >>>> >>>> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. >>>> >>>> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>> >>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >>>> >>>>> All, >>>>> >>>>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >>>>> >>>>> If we can get agreement on this then we can start making progress on the remainder of the document. >>>>> >>>>> Steve >>>>> >>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>> >>>>>>>> One example of the impact of the issue is defined in this message: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>> >>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>>>>> >>>>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>>>>> >>>>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>>>>> >>>>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> --------- >>>>>>>> >>>>>>>> Option 1 Pros: >>>>>>>> ------------ >>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>>>>> >>>>>>>> Option 1 Cons: >>>>>>>> ------------- >>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>> overload control >>>>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>>>>> >>>>>>>> Option 2 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>> management of overload conditions >>>>>>>> >>>>>>>> Option 2 Cons: >>>>>>>> ------------ >>>>>>>> - Requires the operator to lose any functionality enabled by the >>>>>>>> non-DOIC agent until all agents have been upgraded to support >>>>>>>> DOIC >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>> requirement about not interfering with existing network features. >>>>>>> If we had that, Option 2 would not comply.) >>>>>>> >>>>>>>> Option 3 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>> For very limited definitions of "rolled out." >>>>>>> >>>>>>>> Option 3 Cons: >>>>>>>> ------------ >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>> reports are sent) >>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>> - Limits ability of operator to fully control overload >>>>>>>> >>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> 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. >>>> >>>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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. >>> >>> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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. >> >> > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Tue Aug 19 23:21:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F164C1A03F4 for ; Tue, 19 Aug 2014 23:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.269 X-Spam-Level: X-Spam-Status: No, score=-15.269 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGzhW-3IJ3aG for ; Tue, 19 Aug 2014 23:21:49 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062A71A02F6 for ; Tue, 19 Aug 2014 23:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18855; q=dns/txt; s=iport; t=1408515709; x=1409725309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kDVkT/uFQ8TBK71YqPyyo/3GkP81BeYMZeH1I3mTLAw=; b=CuY80Re/wJNtX1LnzdwL8hLsJzFvsF1tNfuRY7NMaVp3cLaRoFDLMuJk bgZajB+to1pmFI33BfQYpJ6ImG9OPcFxRoFqWmNRIYWKxW8afknBsXXjV IY5VTB3DoTeLHzH4QG6CiLtsNHLJl1KfOGMWNaEOEBtsxgU17hJ4fnjOy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFALY99FOtJA2H/2dsb2JhbABRCYMNU1cEzG8Kh1kBgQsWd4QDAQEBBAEBAWsLDAQCAQgRBAEBAQoLEgcnCxQJCAIEAQ0FCAESiCcNwjIXjmoHAwEFAgENETECBQYEgyWBHQWGEYRVhCyCE6Akg11sAYEFAQEeIoEHAQEB X-IronPort-AV: E=Sophos;i="5.01,900,1400025600"; d="scan'208";a="70755624" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 20 Aug 2014 06:21:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7K6LlNm004292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Aug 2014 06:21:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 01:21:47 -0500 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , Steve Donovan , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxfVqBhvX9KFZEqyeV+fWGbNs5vHXswAgAZgQoCACY6AgIAAPboAgACH4wCAAB9igIAAIXaAgAASEwCAAAuUgIAApK0Q Date: Wed, 20 Aug 2014 06:21:46 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.140.44] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iPAqlZHQRrAU_IEQwhxotF9Z2ao Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 06:21:52 -0000 I agree with Lionel on multiple accounts. I don't see any value in alternative 1. In fact, as I had already indicated= , the alternative 1 breaks one or more of existing feature and hence it is = not a solution by itself.=20 Additionally, like any other feature, the operator does not simply enable t= his feature in their network without considerable planning, lab and field t= esting. And this is true for between two operators as well - where the bigg= er issue is whether to expose the overload information between two PLMNs or= not. So I don't see the need to have protocol based solution to help operator de= bug "what they have forgotten about their network". Regards, Nirav.=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, August 19, 2014 8:57 PM To: Steve Donovan; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Hi Steve, If you decide to deploy a proxy modifying the origin-host, it would be for = some specific purposes in a given context. If the context has changed, you = will have to reconsider the whole mechanism. And it is not only related to = DOIC. If not done, this is what I'm calling a bad design: it is not only about th= e implementation of the product itself, it is also about how this product i= s used in the operational network. And I don't buy the argument that an operator might have forgotten that a p= roxy modifying origin-host would have been deployed in the network before t= he introduction of DOIC. About alt 1: >>>>>> 1) Attribution of overload reports. >>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR = AVP. >>>>>> - Reacting node always uses the diameter-id in the OC-OLR report = when applying abatement algorithm logic. >>>>>> - Reacting node detects when there is a difference between the di= ameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a= difference, the reacting node should report on the condition (event/alarm)= . Local policy would determine if the reacting node honors the overload re= port or ignores the overload report. The following question still remain not answered: if the proxy replaces the= origin-host A by origin-host B, the Diameter nodes receiving the answers w= ill "see" B as sender of the answer and will use this id when sending new r= equests with origin-host AVP. So can you remind me how exactly the reacting= node will use the Diameter-id received in the OLR? Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9=A0: mardi 1= 9 ao=FBt 2014 16:46 =C0=A0: MORAND Lionel IMT/OLN; Ben Campbell Cc=A0: dime= @ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternati= ves analysis Lionel, More inline. Steve On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: > Hi Steve, > > See below. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 19= =20 > ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : > dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 > alternatives analysis > > Lionel, > > There are two primary reasons that I think option 1 is important: > > 1) This scenario can result in significant under utilization of resources= , to the extreme of completely shutting down all traffic to the servers beh= ind the Origin-Host Munging Agent (OHMA). > > 2) It gives operates a way to detect the unplanned or forgotten instance = of the OHMA. > > Being able to prevent number 1 is enough reason for me to add the very sm= all amount of additional protocol machinery we are talking about. > > [LM] And I disagree. > > More inline. > [LM] same > > Steve > > On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >> Because a a gent modifying the Origin-host can only be a proxy and a pro= xy is by definition compliant with the application supporting the new OLR-r= elated AVPs, everything else is out of scope of the standardization. > SRD> I don't understand this argument. It is perfectly valid for a > client or server to advertise support for an application and not also sup= port DOIC. Why do you imply that it would be different for an agent? > [LM] A proxy that would modify the origin-host without taking into accoun= t the possible use of this origin-host at the application would be a badly-= designed proxy and should not be used in operational network. SRD2> Consider the following timeline: Date - Event: Sometime in 2011 - Operator installs an agent to do topology hiding or load= balancing or some other function and the agent modifies the origin-host AV= P as part of its logic. In 2011 this works perfectly well for all applicat= ions handled by the agent. Sometime in 2015 - The IETF publishes the DOIC specification. Are you asserting that the agent deployed in 2011 was badly designed becaus= e it did not anticipate the DOIC solution published four years later? > >> Moreover, the real added-value of the addition of the diameter-id in the= OLR does not seem so clear. > SRD> See above. > [LM] still unclear SRD2> Detection of the fact that an OHMA exists so that something intelligent can be done before it results in a total shutdown of the Diamet= er network. > >> Finally, we have agreed that the basic mechanism proposed in the draft m= ay not cover all the use cases (existing or future) and can be enhanced if = required, with or without the need for a IETF standard action. > SRD> The reasons so far for deferring functionality was because it=20 > SRD> would > add risk to the schedule for finishing the core DOIC solution. That is n= ot the case here. We have a very small change to the specification that a= ddresses multiple requirements. > [LM] is there any clear description of what will be the use of this info = by the reacting node? if the proxy replaces the origin-host A by origin-hos= t B, the Diameter nodes receiving the answers will "see" B as sender of the= answer and will use this id when sending new requests with origin-host AVP= . So can you remind me how exactly the reacting node will use the Diameter-= id received in the OLR? SRD> Scroll down an look at the details behind alternative 1. > >> For all these reasons, I would recommend not to add this Diameter-id in = the OLR and to assume that the Origin-host is not changed by agent in the p= ath of the Diameter messages. Some extra text could also be added to clarif= y that proxies modifying the Origin-host would have to be upgraded to manag= e consistently the OLR received in Diameter application messages. >> >> Regards, >> >> Lionel >> >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 >> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >> alternatives analysis >> >> I support Alternative 1, but I'm not sure it's a complete solution. >> >> As Nirav pointed out, it has the potential to leak topology information = past a topology hiding proxy. (Unless we can come up with some attribution = scheme that is not based on Diameter Identity or IP Address.) It may be rea= sonable, to do this, but we would need some guidance to warn operators that= this may happen if they enable DOIC across a non-supporting, topology-hidi= ng proxy. It would become the operator's choice to decide which is more imp= ortant. >> >> The part I find unsatisfying, is what would happen if you had some paths= that supported DOIC (or did not do topology hiding), and some paths that d= on't support DOIC also do topology hiding. This could become a pretty big a= dministrative hit, and violates the spirit and letter of our requirement to= avoid adding lots of configuration work. >> >> OTOH, if we had a mechanism where servers could detect the existence of = a non-DOIC, topology-hiding proxy, this could be at least partially automat= ed. I can think of multiple ways we could make it possible to tell if an im= mediate peer supports DOIC, but not so much for non-adjacent nodes. >> >> On Aug 18, 2014, at 5:01 PM, Steve Donovan wr= ote: >> >>> All, >>> >>> My recommendation on this alternative 1 as it give operators the abilit= y to discover when there is an issue associated with "Origin-Host Munging" = agents. The operators can then take any administrative action necessary to= fix the issue. It is also a more general solution that does not rely on o= ne industries interop procedures. >>> >>> If we can get agreement on this then we can start making progress on th= e remainder of the document. >>> >>> Steve >>> >>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>> Are there other thoughts on the pros and cons of the three proposals f= or resolution of issue #66? >>>> >>>> Steve >>>> >>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>>> >>>>>> All, >>>>>> >>>>>> The issue with pre-DOIC agents changing origin-host was been discuss= ed in this thread: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>> >>>>>> One example of the impact of the issue is defined in this message: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>> >>>>>> So far three solutions have been discussed for this issue: >>>>>> >>>>>> 1) Attribution of overload reports. >>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR = AVP. >>>>>> - Reacting node always uses the diameter-id in the OC-OLR report = when applying abatement algorithm logic. >>>>>> - Reacting node detects when there is a difference between the di= ameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a= difference, the reacting node should report on the condition (event/alarm)= . Local policy would determine if the reacting node honors the overload re= port or ignores the overload report. >>>>> I think the last entry is worth further discussion, but it's probably= more important to make a high level decision first. But, at risk of gettin= g ahead of myself: I have trouble imagining a situation where honoring the = overload report will be harmful, since if there is an intervening OHMA, the= reacting node will not likely have any host-routed requests to the diamete= r-id from the OLR. OTOH, I have trouble imagining where honoring the report= would be useful, for the same reason. >>>>> >>>>>> 2) Configuration in operator's networks to turn off origin-host mung= ing behavior until the agent is upgraded to support DOIC. >>>>>> >>>>>> 3) Configuration of reporting nodes to not send overload reports, ei= ther universally or for transactions that cross the origin-host munging age= nt. >>>>>> >>>>>> I've compiled a starting point for a pros and cons analysis of the t= hree approaches. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> --------- >>>>>> >>>>>> Option 1 Pros: >>>>>> ------------ >>>>>> - Gives operators a mechanism to detect when there is a non-DOIC ori= gin-host-munging agent in the path of a transaction. >>>>>> - Gives operators ability to manage the under utilization issue caus= ed by the non-DOIC agent. >>>>>> - Gives operators the ability to keep features requiring origin-host= munging turned on while DOIC is rolled out. >>>>>> - Leaves the determination of which action to take in this scenario = (honor or ignore overload reports) to operator policy. >>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of conf= iguration required. >>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a s= ingle node overload on the traffic handled by other nodes in the network. >>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of ove= rload in a mixed DOIC environment on the overall capacity of the network. >>>>> Specifically, it complies with the MUST NOT make things worth clause,= but does not comply with the SHOULD reduce overload clause. >>>>> >>>>>> Option 1 Cons: >>>>>> ------------- >>>>>> - Requires additional protocol machinery (minimal) >>>>>> - Does not completely fix the effects of non-DOIC agent on=20 >>>>>> overload control >>>>> One additional con is that, if the OHMA is there for the purposes of = true topology hiding, the identity in the OLR may leak topology information= . >>>>> >>>>>> Option 2 Pros: >>>>>> ------------ >>>>>> - Does not require additional protocol machinery >>>>>> - Does the best job of three alternatives in allowing for=20 >>>>>> management of overload conditions >>>>>> >>>>>> Option 2 Cons: >>>>>> ------------ >>>>>> - Requires the operator to lose any functionality enabled by the=20 >>>>>> non-DOIC agent until all agents have been upgraded to support=20 >>>>>> DOIC >>>>>> - Requires extra configuration (against requirement #6) >>>>>> - There is not way to determine if all non-DOIC origin-host munging = behavior has been turned off until an overload event happens, with potentia= l to have significant negative effects until the offending agent can be fou= nd and the behavior turned off. >>>>>> - Not always possible, as operator doesn't always have control over = non-DOIC agent as it might be in another operators network. Proposal to add= ress this through interop agreements but while this might work in 3GPP scen= arios, not all Diameter deployments are 3GPP driven. >>>>> Since you mentioned the 7068 requirements in the cons for option=20 >>>>> 1, it makes sense to mention them for others. This one misses on=20 >>>>> 6, but seems okay for 12 and 17. (I guess we should have had a=20 >>>>> requirement about not interfering with existing network features. >>>>> If we had that, Option 2 would not comply.) >>>>> >>>>>> Option 3 Pros: >>>>>> ------------ >>>>>> - Does not require additional protocol machinery >>>>>> - Gives operators the ability to keep features requiring origin-host= munging turned on while DOIC is rolled out. >>>>> For very limited definitions of "rolled out." >>>>> >>>>>> Option 3 Cons: >>>>>> ------------ >>>>>> - Requires extra configuration (against requirement #6) >>>>>> - Likely requires extra development in the reporting node that=20 >>>>>> would not otherwise be needed (ability to limit where overload=20 >>>>>> reports are sent) >>>>>> - Not necessarily easy to determine in advance where which=20 >>>>>> requests will traverse a the non-DOIC agent >>>>>> - Limits ability of operator to fully control overload >>>>>> >>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a simi= lar way as option 1. Partially misses 34. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Aug 20 08:54:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66041A0452 for ; Wed, 20 Aug 2014 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8FAT5RfaZCR for ; Wed, 20 Aug 2014 08:54:15 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF3D1A0380 for ; Wed, 20 Aug 2014 08:54:15 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61039 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XK8DD-0004Mu-6x; Wed, 20 Aug 2014 08:54:13 -0700 Message-ID: <53F4C4A3.4070105@usdonovans.com> Date: Wed, 20 Aug 2014 10:54:11 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "lionel.morand@orange.com" , Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/g_LgD7F2zlRixYEV2CRHwIK-x8E Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 15:54:18 -0000 Nirav, Please see my comments inline. Steve On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: > I agree with Lionel on multiple accounts. > I don't see any value in alternative 1. In fact, as I had already indicated, the alternative 1 breaks one or more of existing feature and hence it is not a solution by itself. SRD> The value is that, through a protocol solution, we can make it possible to prevent a complete shutdown of all traffic through a OHMA. It might be a small probability, but it is > 0, the impact is significant and the cost of the proposed protocol solution is extremely small. SRD> I'm assuming that the breakage you are talking about is that the proposal does allow for topology information to leak across operator boundaries. This is true, however, we do not, however, have a requirement to make DOIC work in the face of topology hiding. Are there other existing features that you are concerned about? > > Additionally, like any other feature, the operator does not simply enable this feature in their network without considerable planning, lab and field testing. And this is true for between two operators as well - where the bigger issue is whether to expose the overload information between two PLMNs or not. SRD> We are designing DOIC for Diameter usage in general, not just 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at least for well disciplined operators that have extensive testing as you point out. I don't, however, think we can make that assumption across all uses of Diameter. That's one of the reasons why we have requirements stating that the solution should not rely on configuration. > So I don't see the need to have protocol based solution to help operator debug "what they have forgotten about their network". SRD> As has been pointed out multiple times, this is not just about the operator's own network. The negative impacts can result from another operator not upgrading their agents to support DOIC. SRD> I look at this as a low cost insurance policy. It doesn't hurt anything to add this small change and it helps prevent would could be a major outage. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: Tuesday, August 19, 2014 8:57 PM > To: Steve Donovan; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > Hi Steve, > > If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC. > If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network. > And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC. > > About alt 1: > >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. > The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi 19 août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > Lionel, > > More inline. > > Steve > > On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> See below. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi 19 >> août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >> alternatives analysis >> >> Lionel, >> >> There are two primary reasons that I think option 1 is important: >> >> 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). >> >> 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. >> >> Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. >> >> [LM] And I disagree. >> >> More inline. >> [LM] same >> >> Steve >> >> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. >> SRD> I don't understand this argument. It is perfectly valid for a >> client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? >> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network. > SRD2> Consider the following timeline: > > Date - Event: > > Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic. In 2011 this works perfectly well for all applications handled by the agent. > > Sometime in 2015 - The IETF publishes the DOIC specification. > > Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later? >>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. >> SRD> See above. >> [LM] still unclear > SRD2> Detection of the fact that an OHMA exists so that something > intelligent can be done before it results in a total shutdown of the Diameter network. >>> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. >> SRD> The reasons so far for deferring functionality was because it >> SRD> would >> add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. >> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? > SRD> Scroll down an look at the details behind alternative 1. >>> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> I support Alternative 1, but I'm not sure it's a complete solution. >>> >>> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. >>> >>> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. >>> >>> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. >>> >>> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >>> >>>> All, >>>> >>>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >>>> >>>> If we can get agreement on this then we can start making progress on the remainder of the document. >>>> >>>> Steve >>>> >>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>>>> >>>>> Steve >>>>> >>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>> >>>>>>> One example of the impact of the issue is defined in this message: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>> >>>>>>> So far three solutions have been discussed for this issue: >>>>>>> >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>>>> >>>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>>>> >>>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>>>> >>>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Option 1 Pros: >>>>>>> ------------ >>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>>>> >>>>>>> Option 1 Cons: >>>>>>> ------------- >>>>>>> - Requires additional protocol machinery (minimal) >>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>> overload control >>>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>>>> >>>>>>> Option 2 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Does the best job of three alternatives in allowing for >>>>>>> management of overload conditions >>>>>>> >>>>>>> Option 2 Cons: >>>>>>> ------------ >>>>>>> - Requires the operator to lose any functionality enabled by the >>>>>>> non-DOIC agent until all agents have been upgraded to support >>>>>>> DOIC >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>> requirement about not interfering with existing network features. >>>>>> If we had that, Option 2 would not comply.) >>>>>> >>>>>>> Option 3 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>> For very limited definitions of "rolled out." >>>>>> >>>>>>> Option 3 Cons: >>>>>>> ------------ >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - Likely requires extra development in the reporting node that >>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>> reports are sent) >>>>>>> - Not necessarily easy to determine in advance where which >>>>>>> requests will traverse a the non-DOIC agent >>>>>>> - Limits ability of operator to fully control overload >>>>>>> >>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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. >>> >>> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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. >> >> > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Aug 20 08:59:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C3C1A0ADB for ; Wed, 20 Aug 2014 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.169 X-Spam-Level: X-Spam-Status: No, score=-17.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX4hDDxU6mWw for ; Wed, 20 Aug 2014 08:59:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECDD1A093B for ; Wed, 20 Aug 2014 08:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21294; q=dns/txt; s=iport; t=1408550376; x=1409759976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wQJuo2yVsXQwgFmahR2Jw4jc0VR/jE8ElKeFwbDysxw=; b=EcFbni+yDnsztM59tw+UgZ9WE83g6yqlzzv0F3niXTeMaloKFPYpKesz PnHynFUncwQma/D6VYKlk7/AY+XVM9ujMUOlg4jcuwmIyQSUyL5Jxo6pZ iMOQwKmW7MPZaOAY7r4Bp2RPvekT9mErV1exCsRF/bc9CQr9jifSVW7l9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FACnF9FOtJV2T/2dsb2JhbABQCYMNU1cEzD8Kh1kBgRAWd4QDAQEBBAEBAWsLDAQCAQgOAwQBAQEKCxIHJwsUCQgCBAENBQgBEognDcJUF4cOh1wHAwEFAgENETECBQYEgyWBHQWGEYRVhCyCE6Apg11sAYEFAQEeIoEHAQEB X-IronPort-AV: E=Sophos;i="5.01,903,1400025600"; d="scan'208";a="348982237" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 20 Aug 2014 15:59:34 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7KFxYc9019924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Aug 2014 15:59:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 10:59:34 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxfVqBhvX9KFZEqyeV+fWGbNs5vHXswAgAZgQoCACY6AgIAAPboAgACH4wCAAB9igIAAIXaAgAASEwCAAAuUgIAApK0QgAD1QoD//60HEA== Date: Wed, 20 Aug 2014 15:59:33 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> In-Reply-To: <53F4C4A3.4070105@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.83] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bSWYRTAfnjXhhpACUahkkVYVw28 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 15:59:40 -0000 Steve, I don't agree with your explanations. Additionally, we may not have explicit requirement to make DOIC work in the= face of topology hiding but that does not mean that "DOIC can break any ex= isting feature - be it topology hiding - and that's fine!". Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, August 20, 2014 9:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Nirav, Please see my comments inline. Steve On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: > I agree with Lionel on multiple accounts. > I don't see any value in alternative 1. In fact, as I had already indicat= ed, the alternative 1 breaks one or more of existing feature and hence it i= s not a solution by itself. SRD> The value is that, through a protocol solution, we can make it possible to prevent a complete shutdown of all traffic through a OHMA. =20 It might be a small probability, but it is > 0, the impact is significant a= nd the cost of the proposed protocol solution is extremely small. SRD> I'm assuming that the breakage you are talking about is that the proposal does allow for topology information to leak across operator bounda= ries. This is true, however, we do not, however, have a requirement to mak= e DOIC work in the face of topology hiding. Are there other existing featu= res that you are concerned about? > > Additionally, like any other feature, the operator does not simply enable= this feature in their network without considerable planning, lab and field= testing. And this is true for between two operators as well - where the bi= gger issue is whether to expose the overload information between two PLMNs = or not. SRD> We are designing DOIC for Diameter usage in general, not just 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at lea= st for well disciplined operators that have extensive testing as you point = out. I don't, however, think we can make that assumption across all uses o= f Diameter. That's one of the reasons why we have requirements stating tha= t the solution should not rely on configuration. > So I don't see the need to have protocol based solution to help operator = debug "what they have forgotten about their network". SRD> As has been pointed out multiple times, this is not just about the operator's own network. The negative impacts can result from another opera= tor not upgrading their agents to support DOIC. SRD> I look at this as a low cost insurance policy. It doesn't hurt anything to add this small change and it helps prevent would could be a maj= or outage. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: Tuesday, August 19, 2014 8:57 PM > To: Steve Donovan; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives=20 > analysis > > Hi Steve, > > If you decide to deploy a proxy modifying the origin-host, it would be fo= r some specific purposes in a given context. If the context has changed, yo= u will have to reconsider the whole mechanism. And it is not only related t= o DOIC. > If not done, this is what I'm calling a bad design: it is not only about = the implementation of the product itself, it is also about how this product= is used in the operational network. > And I don't buy the argument that an operator might have forgotten that a= proxy modifying origin-host would have been deployed in the network before= the introduction of DOIC. > > About alt 1: > >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OL= R AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR repor= t when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is= a difference, the reacting node should report on the condition (event/alar= m). Local policy would determine if the reacting node honors the overload = report or ignores the overload report. > The following question still remain not answered: if the proxy replaces t= he origin-host A by origin-host B, the Diameter nodes receiving the answers= will "see" B as sender of the answer and will use this id when sending new= requests with origin-host AVP. So can you remind me how exactly the reacti= ng node will use the Diameter-id received in the OLR? > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 19= =20 > ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc :=20 > dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 > alternatives analysis > > Lionel, > > More inline. > > Steve > > On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> See below. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi=20 >> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >> alternatives analysis >> >> Lionel, >> >> There are two primary reasons that I think option 1 is important: >> >> 1) This scenario can result in significant under utilization of resource= s, to the extreme of completely shutting down all traffic to the servers be= hind the Origin-Host Munging Agent (OHMA). >> >> 2) It gives operates a way to detect the unplanned or forgotten instance= of the OHMA. >> >> Being able to prevent number 1 is enough reason for me to add the very s= mall amount of additional protocol machinery we are talking about. >> >> [LM] And I disagree. >> >> More inline. >> [LM] same >> >> Steve >> >> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>> Because a a gent modifying the Origin-host can only be a proxy and a pr= oxy is by definition compliant with the application supporting the new OLR-= related AVPs, everything else is out of scope of the standardization. >> SRD> I don't understand this argument. It is perfectly valid for a >> client or server to advertise support for an application and not also su= pport DOIC. Why do you imply that it would be different for an agent? >> [LM] A proxy that would modify the origin-host without taking into accou= nt the possible use of this origin-host at the application would be a badly= -designed proxy and should not be used in operational network. > SRD2> Consider the following timeline: > > Date - Event: > > Sometime in 2011 - Operator installs an agent to do topology hiding or lo= ad balancing or some other function and the agent modifies the origin-host = AVP as part of its logic. In 2011 this works perfectly well for all applic= ations handled by the agent. > > Sometime in 2015 - The IETF publishes the DOIC specification. > > Are you asserting that the agent deployed in 2011 was badly designed beca= use it did not anticipate the DOIC solution published four years later? >>> Moreover, the real added-value of the addition of the diameter-id in th= e OLR does not seem so clear. >> SRD> See above. >> [LM] still unclear > SRD2> Detection of the fact that an OHMA exists so that something > intelligent can be done before it results in a total shutdown of the Diam= eter network. >>> Finally, we have agreed that the basic mechanism proposed in the draft = may not cover all the use cases (existing or future) and can be enhanced if= required, with or without the need for a IETF standard action. >> SRD> The reasons so far for deferring functionality was because it=20 >> SRD> would >> add risk to the schedule for finishing the core DOIC solution. That is = not the case here. We have a very small change to the specification that = addresses multiple requirements. >> [LM] is there any clear description of what will be the use of this info= by the reacting node? if the proxy replaces the origin-host A by origin-ho= st B, the Diameter nodes receiving the answers will "see" B as sender of th= e answer and will use this id when sending new requests with origin-host AV= P. So can you remind me how exactly the reacting node will use the Diameter= -id received in the OLR? > SRD> Scroll down an look at the details behind alternative 1. >>> For all these reasons, I would recommend not to add this Diameter-id in= the OLR and to assume that the Origin-host is not changed by agent in the = path of the Diameter messages. Some extra text could also be added to clari= fy that proxies modifying the Origin-host would have to be upgraded to mana= ge consistently the OLR received in Diameter application messages. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 >>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >>> alternatives analysis >>> >>> I support Alternative 1, but I'm not sure it's a complete solution. >>> >>> As Nirav pointed out, it has the potential to leak topology information= past a topology hiding proxy. (Unless we can come up with some attribution= scheme that is not based on Diameter Identity or IP Address.) It may be re= asonable, to do this, but we would need some guidance to warn operators tha= t this may happen if they enable DOIC across a non-supporting, topology-hid= ing proxy. It would become the operator's choice to decide which is more im= portant. >>> >>> The part I find unsatisfying, is what would happen if you had some path= s that supported DOIC (or did not do topology hiding), and some paths that = don't support DOIC also do topology hiding. This could become a pretty big = administrative hit, and violates the spirit and letter of our requirement t= o avoid adding lots of configuration work. >>> >>> OTOH, if we had a mechanism where servers could detect the existence of= a non-DOIC, topology-hiding proxy, this could be at least partially automa= ted. I can think of multiple ways we could make it possible to tell if an i= mmediate peer supports DOIC, but not so much for non-adjacent nodes. >>> >>> On Aug 18, 2014, at 5:01 PM, Steve Donovan w= rote: >>> >>>> All, >>>> >>>> My recommendation on this alternative 1 as it give operators the abili= ty to discover when there is an issue associated with "Origin-Host Munging"= agents. The operators can then take any administrative action necessary t= o fix the issue. It is also a more general solution that does not rely on = one industries interop procedures. >>>> >>>> If we can get agreement on this then we can start making progress on t= he remainder of the document. >>>> >>>> Steve >>>> >>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>> Are there other thoughts on the pros and cons of the three proposals = for resolution of issue #66? >>>>> >>>>> Steve >>>>> >>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> The issue with pre-DOIC agents changing origin-host was been discus= sed in this thread: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>> >>>>>>> One example of the impact of the issue is defined in this message: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>> >>>>>>> So far three solutions have been discussed for this issue: >>>>>>> >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OL= R AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR repor= t when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is= a difference, the reacting node should report on the condition (event/alar= m). Local policy would determine if the reacting node honors the overload = report or ignores the overload report. >>>>>> I think the last entry is worth further discussion, but it's probabl= y more important to make a high level decision first. But, at risk of getti= ng ahead of myself: I have trouble imagining a situation where honoring the= overload report will be harmful, since if there is an intervening OHMA, th= e reacting node will not likely have any host-routed requests to the diamet= er-id from the OLR. OTOH, I have trouble imagining where honoring the repor= t would be useful, for the same reason. >>>>>> >>>>>>> 2) Configuration in operator's networks to turn off origin-host mun= ging behavior until the agent is upgraded to support DOIC. >>>>>>> >>>>>>> 3) Configuration of reporting nodes to not send overload reports, e= ither universally or for transactions that cross the origin-host munging ag= ent. >>>>>>> >>>>>>> I've compiled a starting point for a pros and cons analysis of the = three approaches. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Option 1 Pros: >>>>>>> ------------ >>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC or= igin-host-munging agent in the path of a transaction. >>>>>>> - Gives operators ability to manage the under utilization issue cau= sed by the non-DOIC agent. >>>>>>> - Gives operators the ability to keep features requiring origin-hos= t munging turned on while DOIC is rolled out. >>>>>>> - Leaves the determination of which action to take in this scenario= (honor or ignore overload reports) to operator policy. >>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of con= figuration required. >>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a = single node overload on the traffic handled by other nodes in the network. >>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of ov= erload in a mixed DOIC environment on the overall capacity of the network. >>>>>> Specifically, it complies with the MUST NOT make things worth clause= , but does not comply with the SHOULD reduce overload clause. >>>>>> >>>>>>> Option 1 Cons: >>>>>>> ------------- >>>>>>> - Requires additional protocol machinery (minimal) >>>>>>> - Does not completely fix the effects of non-DOIC agent on=20 >>>>>>> overload control >>>>>> One additional con is that, if the OHMA is there for the purposes of= true topology hiding, the identity in the OLR may leak topology informatio= n. >>>>>> >>>>>>> Option 2 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Does the best job of three alternatives in allowing for=20 >>>>>>> management of overload conditions >>>>>>> >>>>>>> Option 2 Cons: >>>>>>> ------------ >>>>>>> - Requires the operator to lose any functionality enabled by the=20 >>>>>>> non-DOIC agent until all agents have been upgraded to support=20 >>>>>>> DOIC >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - There is not way to determine if all non-DOIC origin-host munging= behavior has been turned off until an overload event happens, with potenti= al to have significant negative effects until the offending agent can be fo= und and the behavior turned off. >>>>>>> - Not always possible, as operator doesn't always have control over= non-DOIC agent as it might be in another operators network. Proposal to ad= dress this through interop agreements but while this might work in 3GPP sce= narios, not all Diameter deployments are 3GPP driven. >>>>>> Since you mentioned the 7068 requirements in the cons for option=20 >>>>>> 1, it makes sense to mention them for others. This one misses on=20 >>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a=20 >>>>>> requirement about not interfering with existing network features. >>>>>> If we had that, Option 2 would not comply.) >>>>>> >>>>>>> Option 3 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Gives operators the ability to keep features requiring origin-hos= t munging turned on while DOIC is rolled out. >>>>>> For very limited definitions of "rolled out." >>>>>> >>>>>>> Option 3 Cons: >>>>>>> ------------ >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - Likely requires extra development in the reporting node that=20 >>>>>>> would not otherwise be needed (ability to limit where overload=20 >>>>>>> reports are sent) >>>>>>> - Not necessarily easy to determine in advance where which=20 >>>>>>> requests will traverse a the non-DOIC agent >>>>>>> - Limits ability of operator to fully control overload >>>>>>> >>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a sim= ilar way as option 1. Partially misses 34. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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 i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Aug 20 09:17:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A80E1A6FD3 for ; Wed, 20 Aug 2014 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEWzn_p0V2ys for ; Wed, 20 Aug 2014 09:17:24 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0477F1A6FB6 for ; Wed, 20 Aug 2014 09:17:23 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 12:17:22 -0400 From: Dave Dolson To: Steve Donovan , "Nirav Salot (nsalot)" , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxgPhiKpR/5U7Ei7ySD2CsfBHZvHTggAgAZgQoCACY6AgIAAPboAgACH4wCAAB9igIAAIXaAgAASEwCAAAuUgIAA+gAAgACf74D//8HbcA== Date: Wed, 20 Aug 2014 16:17:21 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> In-Reply-To: <53F4C4A3.4070105@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QJw3o1Dez7dNVUnsrRciin7FC70 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 16:17:29 -0000 It seems to me that this stale-mate may be addressed by observing that the = host name has been introduced to distinguish between multiple reports, and = that any unique key would allow this. Would it be acceptable to make the field any arbitrary unique key rather th= an the host name? (Host name is a special case of arbitrary unique key) Then a receiver would recognize that reports are coming from multiple sourc= es without any reveal of actual host names. Those concerned about AVP size could use 4-byte discriminators; those conce= rned about global uniqueness could use the host name. -Dave. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, August 20, 2014 11:54 AM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Nirav, Please see my comments inline. Steve On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: > I agree with Lionel on multiple accounts. > I don't see any value in alternative 1. In fact, as I had already indicat= ed, the alternative 1 breaks one or more of existing feature and hence it i= s not a solution by itself. SRD> The value is that, through a protocol solution, we can make it=20 possible to prevent a complete shutdown of all traffic through a OHMA. =20 It might be a small probability, but it is > 0, the impact is=20 significant and the cost of the proposed protocol solution is extremely=20 small. SRD> I'm assuming that the breakage you are talking about is that the=20 proposal does allow for topology information to leak across operator=20 boundaries. This is true, however, we do not, however, have a=20 requirement to make DOIC work in the face of topology hiding. Are there=20 other existing features that you are concerned about? > > Additionally, like any other feature, the operator does not simply enable= this feature in their network without considerable planning, lab and field= testing. And this is true for between two operators as well - where the bi= gger issue is whether to expose the overload information between two PLMNs = or not. SRD> We are designing DOIC for Diameter usage in general, not just=20 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at=20 least for well disciplined operators that have extensive testing as you=20 point out. I don't, however, think we can make that assumption across=20 all uses of Diameter. That's one of the reasons why we have=20 requirements stating that the solution should not rely on configuration. > So I don't see the need to have protocol based solution to help operator = debug "what they have forgotten about their network". SRD> As has been pointed out multiple times, this is not just about the=20 operator's own network. The negative impacts can result from another=20 operator not upgrading their agents to support DOIC. SRD> I look at this as a low cost insurance policy. It doesn't hurt=20 anything to add this small change and it helps prevent would could be a=20 major outage. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@oran= ge.com > Sent: Tuesday, August 19, 2014 8:57 PM > To: Steve Donovan; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analy= sis > > Hi Steve, > > If you decide to deploy a proxy modifying the origin-host, it would be fo= r some specific purposes in a given context. If the context has changed, yo= u will have to reconsider the whole mechanism. And it is not only related t= o DOIC. > If not done, this is what I'm calling a bad design: it is not only about = the implementation of the product itself, it is also about how this product= is used in the operational network. > And I don't buy the argument that an operator might have forgotten that a= proxy modifying origin-host would have been deployed in the network before= the introduction of DOIC. > > About alt 1: > >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OL= R AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR repor= t when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is= a difference, the reacting node should report on the condition (event/alar= m). Local policy would determine if the reacting node honors the overload = report or ignores the overload report. > The following question still remain not answered: if the proxy replaces t= he origin-host A by origin-host B, the Diameter nodes receiving the answers= will "see" B as sender of the answer and will use this id when sending new= requests with origin-host AVP. So can you remind me how exactly the reacti= ng node will use the Diameter-id received in the OLR? > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 19 = ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : dime@ietf.= org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives anal= ysis > > Lionel, > > More inline. > > Steve > > On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >> Hi Steve, >> >> See below. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 19 >> ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >> alternatives analysis >> >> Lionel, >> >> There are two primary reasons that I think option 1 is important: >> >> 1) This scenario can result in significant under utilization of resource= s, to the extreme of completely shutting down all traffic to the servers be= hind the Origin-Host Munging Agent (OHMA). >> >> 2) It gives operates a way to detect the unplanned or forgotten instance= of the OHMA. >> >> Being able to prevent number 1 is enough reason for me to add the very s= mall amount of additional protocol machinery we are talking about. >> >> [LM] And I disagree. >> >> More inline. >> [LM] same >> >> Steve >> >> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>> Because a a gent modifying the Origin-host can only be a proxy and a pr= oxy is by definition compliant with the application supporting the new OLR-= related AVPs, everything else is out of scope of the standardization. >> SRD> I don't understand this argument. It is perfectly valid for a >> client or server to advertise support for an application and not also su= pport DOIC. Why do you imply that it would be different for an agent? >> [LM] A proxy that would modify the origin-host without taking into accou= nt the possible use of this origin-host at the application would be a badly= -designed proxy and should not be used in operational network. > SRD2> Consider the following timeline: > > Date - Event: > > Sometime in 2011 - Operator installs an agent to do topology hiding or lo= ad balancing or some other function and the agent modifies the origin-host = AVP as part of its logic. In 2011 this works perfectly well for all applic= ations handled by the agent. > > Sometime in 2015 - The IETF publishes the DOIC specification. > > Are you asserting that the agent deployed in 2011 was badly designed beca= use it did not anticipate the DOIC solution published four years later? >>> Moreover, the real added-value of the addition of the diameter-id in th= e OLR does not seem so clear. >> SRD> See above. >> [LM] still unclear > SRD2> Detection of the fact that an OHMA exists so that something > intelligent can be done before it results in a total shutdown of the Diam= eter network. >>> Finally, we have agreed that the basic mechanism proposed in the draft = may not cover all the use cases (existing or future) and can be enhanced if= required, with or without the need for a IETF standard action. >> SRD> The reasons so far for deferring functionality was because it >> SRD> would >> add risk to the schedule for finishing the core DOIC solution. That is = not the case here. We have a very small change to the specification that = addresses multiple requirements. >> [LM] is there any clear description of what will be the use of this info= by the reacting node? if the proxy replaces the origin-host A by origin-ho= st B, the Diameter nodes receiving the answers will "see" B as sender of th= e answer and will use this id when sending new requests with origin-host AV= P. So can you remind me how exactly the reacting node will use the Diameter= -id received in the OLR? > SRD> Scroll down an look at the details behind alternative 1. >>> For all these reasons, I would recommend not to add this Diameter-id in= the OLR and to assume that the Origin-host is not changed by agent in the = path of the Diameter messages. Some extra text could also be added to clari= fy that proxies modifying the Origin-host would have to be upgraded to mana= ge consistently the OLR received in Diameter application messages. >>> >>> Regards, >>> >>> Lionel >>> >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> I support Alternative 1, but I'm not sure it's a complete solution. >>> >>> As Nirav pointed out, it has the potential to leak topology information= past a topology hiding proxy. (Unless we can come up with some attribution= scheme that is not based on Diameter Identity or IP Address.) It may be re= asonable, to do this, but we would need some guidance to warn operators tha= t this may happen if they enable DOIC across a non-supporting, topology-hid= ing proxy. It would become the operator's choice to decide which is more im= portant. >>> >>> The part I find unsatisfying, is what would happen if you had some path= s that supported DOIC (or did not do topology hiding), and some paths that = don't support DOIC also do topology hiding. This could become a pretty big = administrative hit, and violates the spirit and letter of our requirement t= o avoid adding lots of configuration work. >>> >>> OTOH, if we had a mechanism where servers could detect the existence of= a non-DOIC, topology-hiding proxy, this could be at least partially automa= ted. I can think of multiple ways we could make it possible to tell if an i= mmediate peer supports DOIC, but not so much for non-adjacent nodes. >>> >>> On Aug 18, 2014, at 5:01 PM, Steve Donovan w= rote: >>> >>>> All, >>>> >>>> My recommendation on this alternative 1 as it give operators the abili= ty to discover when there is an issue associated with "Origin-Host Munging"= agents. The operators can then take any administrative action necessary t= o fix the issue. It is also a more general solution that does not rely on = one industries interop procedures. >>>> >>>> If we can get agreement on this then we can start making progress on t= he remainder of the document. >>>> >>>> Steve >>>> >>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>> Are there other thoughts on the pros and cons of the three proposals = for resolution of issue #66? >>>>> >>>>> Steve >>>>> >>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> The issue with pre-DOIC agents changing origin-host was been discus= sed in this thread: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>> >>>>>>> One example of the impact of the issue is defined in this message: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>> >>>>>>> So far three solutions have been discussed for this issue: >>>>>>> >>>>>>> 1) Attribution of overload reports. >>>>>>> - Add diameter-id of the node that is overloaded into the OC-OL= R AVP. >>>>>>> - Reacting node always uses the diameter-id in the OC-OLR repor= t when applying abatement algorithm logic. >>>>>>> - Reacting node detects when there is a difference between the = diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is= a difference, the reacting node should report on the condition (event/alar= m). Local policy would determine if the reacting node honors the overload = report or ignores the overload report. >>>>>> I think the last entry is worth further discussion, but it's probabl= y more important to make a high level decision first. But, at risk of getti= ng ahead of myself: I have trouble imagining a situation where honoring the= overload report will be harmful, since if there is an intervening OHMA, th= e reacting node will not likely have any host-routed requests to the diamet= er-id from the OLR. OTOH, I have trouble imagining where honoring the repor= t would be useful, for the same reason. >>>>>> >>>>>>> 2) Configuration in operator's networks to turn off origin-host mun= ging behavior until the agent is upgraded to support DOIC. >>>>>>> >>>>>>> 3) Configuration of reporting nodes to not send overload reports, e= ither universally or for transactions that cross the origin-host munging ag= ent. >>>>>>> >>>>>>> I've compiled a starting point for a pros and cons analysis of the = three approaches. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Option 1 Pros: >>>>>>> ------------ >>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC or= igin-host-munging agent in the path of a transaction. >>>>>>> - Gives operators ability to manage the under utilization issue cau= sed by the non-DOIC agent. >>>>>>> - Gives operators the ability to keep features requiring origin-hos= t munging turned on while DOIC is rolled out. >>>>>>> - Leaves the determination of which action to take in this scenario= (honor or ignore overload reports) to operator policy. >>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of con= figuration required. >>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a = single node overload on the traffic handled by other nodes in the network. >>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of ov= erload in a mixed DOIC environment on the overall capacity of the network. >>>>>> Specifically, it complies with the MUST NOT make things worth clause= , but does not comply with the SHOULD reduce overload clause. >>>>>> >>>>>>> Option 1 Cons: >>>>>>> ------------- >>>>>>> - Requires additional protocol machinery (minimal) >>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>> overload control >>>>>> One additional con is that, if the OHMA is there for the purposes of= true topology hiding, the identity in the OLR may leak topology informatio= n. >>>>>> >>>>>>> Option 2 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Does the best job of three alternatives in allowing for >>>>>>> management of overload conditions >>>>>>> >>>>>>> Option 2 Cons: >>>>>>> ------------ >>>>>>> - Requires the operator to lose any functionality enabled by the >>>>>>> non-DOIC agent until all agents have been upgraded to support >>>>>>> DOIC >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - There is not way to determine if all non-DOIC origin-host munging= behavior has been turned off until an overload event happens, with potenti= al to have significant negative effects until the offending agent can be fo= und and the behavior turned off. >>>>>>> - Not always possible, as operator doesn't always have control over= non-DOIC agent as it might be in another operators network. Proposal to ad= dress this through interop agreements but while this might work in 3GPP sce= narios, not all Diameter deployments are 3GPP driven. >>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>> requirement about not interfering with existing network features. >>>>>> If we had that, Option 2 would not comply.) >>>>>> >>>>>>> Option 3 Pros: >>>>>>> ------------ >>>>>>> - Does not require additional protocol machinery >>>>>>> - Gives operators the ability to keep features requiring origin-hos= t munging turned on while DOIC is rolled out. >>>>>> For very limited definitions of "rolled out." >>>>>> >>>>>>> Option 3 Cons: >>>>>>> ------------ >>>>>>> - Requires extra configuration (against requirement #6) >>>>>>> - Likely requires extra development in the reporting node that >>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>> reports are sent) >>>>>>> - Not necessarily easy to determine in advance where which >>>>>>> requests will traverse a the non-DOIC agent >>>>>>> - Limits ability of operator to fully control overload >>>>>>> >>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a sim= ilar way as option 1. Partially misses 34. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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 qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, Orange decline toute responsabilite si ce message a ete altere, defo= rme 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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 i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Aug 20 09:26:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EBC1A0700 for ; Wed, 20 Aug 2014 09:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Eew57yvOBtx for ; Wed, 20 Aug 2014 09:25:50 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF771A0AD5 for ; Wed, 20 Aug 2014 09:25:50 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61243 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XK8hl-0007pS-6k; Wed, 20 Aug 2014 09:25:48 -0700 Message-ID: <53F4CC09.6000208@usdonovans.com> Date: Wed, 20 Aug 2014 11:25:45 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "lionel.morand@orange.com" , Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dExzhBWyzMLceVqvAnAwIC9TOKE Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 16:25:58 -0000 Nirav, Can you please be more specific about which of the explanations you don't agree with? I agree we can't completely ignore the way that Diameter is being used. We should also be avoiding a solution that leaves open the possibility of significant under utilization of Diameter network resources. We have a stated requirement that the solution must not result in under utilization. I must admit I'm surprised at the response the proposal is getting. It is a very minor change that makes the protocol more resilient. Steve On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: > Steve, > > I don't agree with your explanations. > > Additionally, we may not have explicit requirement to make DOIC work in the face of topology hiding but that does not mean that "DOIC can break any existing feature - be it topology hiding - and that's fine!". > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:24 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > Nirav, > > Please see my comments inline. > > Steve > > On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >> I agree with Lionel on multiple accounts. >> I don't see any value in alternative 1. In fact, as I had already indicated, the alternative 1 breaks one or more of existing feature and hence it is not a solution by itself. > SRD> The value is that, through a protocol solution, we can make it > possible to prevent a complete shutdown of all traffic through a OHMA. > It might be a small probability, but it is > 0, the impact is significant and the cost of the proposed protocol solution is extremely small. > > SRD> I'm assuming that the breakage you are talking about is that the > proposal does allow for topology information to leak across operator boundaries. This is true, however, we do not, however, have a requirement to make DOIC work in the face of topology hiding. Are there other existing features that you are concerned about? >> Additionally, like any other feature, the operator does not simply enable this feature in their network without considerable planning, lab and field testing. And this is true for between two operators as well - where the bigger issue is whether to expose the overload information between two PLMNs or not. > SRD> We are designing DOIC for Diameter usage in general, not just > 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at least for well disciplined operators that have extensive testing as you point out. I don't, however, think we can make that assumption across all uses of Diameter. That's one of the reasons why we have requirements stating that the solution should not rely on configuration. >> So I don't see the need to have protocol based solution to help operator debug "what they have forgotten about their network". > SRD> As has been pointed out multiple times, this is not just about the > operator's own network. The negative impacts can result from another operator not upgrading their agents to support DOIC. > > SRD> I look at this as a low cost insurance policy. It doesn't hurt > anything to add this small change and it helps prevent would could be a major outage. >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >> lionel.morand@orange.com >> Sent: Tuesday, August 19, 2014 8:57 PM >> To: Steve Donovan; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> Hi Steve, >> >> If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC. >> If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network. >> And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC. >> >> About alt 1: >> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >> The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi 19 >> août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >> alternatives analysis >> >> Lionel, >> >> More inline. >> >> Steve >> >> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> See below. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi >>> 19 août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> There are two primary reasons that I think option 1 is important: >>> >>> 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). >>> >>> 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. >>> >>> Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. >>> >>> [LM] And I disagree. >>> >>> More inline. >>> [LM] same >>> >>> Steve >>> >>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. >>> SRD> I don't understand this argument. It is perfectly valid for a >>> client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? >>> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network. >> SRD2> Consider the following timeline: >> >> Date - Event: >> >> Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic. In 2011 this works perfectly well for all applications handled by the agent. >> >> Sometime in 2015 - The IETF publishes the DOIC specification. >> >> Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later? >>>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. >>> SRD> See above. >>> [LM] still unclear >> SRD2> Detection of the fact that an OHMA exists so that something >> intelligent can be done before it results in a total shutdown of the Diameter network. >>>> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. >>> SRD> The reasons so far for deferring functionality was because it >>> SRD> would >>> add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. >>> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? >> SRD> Scroll down an look at the details behind alternative 1. >>>> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>> >>>> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. >>>> >>>> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. >>>> >>>> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>> >>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >>>> >>>>> All, >>>>> >>>>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >>>>> >>>>> If we can get agreement on this then we can start making progress on the remainder of the document. >>>>> >>>>> Steve >>>>> >>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>> >>>>>>>> One example of the impact of the issue is defined in this message: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>> >>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>>>>> >>>>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>>>>> >>>>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>>>>> >>>>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> --------- >>>>>>>> >>>>>>>> Option 1 Pros: >>>>>>>> ------------ >>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>>>>> >>>>>>>> Option 1 Cons: >>>>>>>> ------------- >>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>> overload control >>>>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>>>>> >>>>>>>> Option 2 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>> management of overload conditions >>>>>>>> >>>>>>>> Option 2 Cons: >>>>>>>> ------------ >>>>>>>> - Requires the operator to lose any functionality enabled by the >>>>>>>> non-DOIC agent until all agents have been upgraded to support >>>>>>>> DOIC >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>> requirement about not interfering with existing network features. >>>>>>> If we had that, Option 2 would not comply.) >>>>>>> >>>>>>>> Option 3 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>> For very limited definitions of "rolled out." >>>>>>> >>>>>>>> Option 3 Cons: >>>>>>>> ------------ >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>> reports are sent) >>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>> - Limits ability of operator to fully control overload >>>>>>>> >>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> 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. >>>> >>>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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. >>> >>> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Wed Aug 20 09:43:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC361A03E6 for ; Wed, 20 Aug 2014 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.169 X-Spam-Level: X-Spam-Status: No, score=-17.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4eDxBF_B01z for ; Wed, 20 Aug 2014 09:43:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629E21A03DF for ; Wed, 20 Aug 2014 09:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24206; q=dns/txt; s=iport; t=1408553007; x=1409762607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TCoBRpKvP3fOqxKR8no7VP0XuJ6qgy5r+PHn4X618Ac=; b=U48acfP8G+I3VuplXevtA/uKHayWqh5wgi8wI+/V/I2NfTWBJWG5Y12g 5uZS0VimJPaUGhVFMlTn9SfbkSLWt+JK7Bg6k8ZxLlgbgk3PezyTn70Wn Qua2f6vlQ1k89IZt2KbOm1G/1JZIB+rHtB7rETTpou7OiLri9z5bH5OCe g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAPPP9FOtJA2J/2dsb2JhbABQCYMNU1cEzD8Kh1kBgRAWd4QDAQEBBAEBARdUCwwEAgEIDgMEAQEBCgsSBycLFAkIAgQBDQUIARKIJw3CYheHDodcBwMBBQIBDRExAgUGBIMlgR0FhhGEVYY/oCmDXWwBgQUBAR4igQcBAQE X-IronPort-AV: E=Sophos;i="5.01,903,1400025600"; d="scan'208";a="70916532" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 20 Aug 2014 16:43:10 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7KGhAm0030914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Aug 2014 16:43:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 11:43:09 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxfVqBhvX9KFZEqyeV+fWGbNs5vHXswAgAZgQoCACY6AgIAAPboAgACH4wCAAB9igIAAIXaAgAASEwCAAAuUgIAApK0QgAD1QoD//60HEIAAW8uA//+sc4A= Date: Wed, 20 Aug 2014 16:43:09 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> In-Reply-To: <53F4CC09.6000208@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.83] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jBnrlTlDyEYQpt-1RisScq2k694 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 16:43:31 -0000 Steve, You are proposing a change (minor or not) for a problem which does not exis= t (in my view at least) since the use case is - The operator has enabled overload feature in his network and has not upgr= aded one of the proxy - The operator has "forgotten" that the proxy which is not upgraded is doin= g topology hiding Or between two operators, they have entered into the agreement to share the= overload reports but have not bothered to upgrade all of their nodes and n= ot done any basic testing before activating the overload feature.=20 So we are defining the solution for the above use cases. And the solution y= ou are suggesting it results in - The client ignoring the overload report and thus the operator finds out t= hat "he has forgotten to upgrade one of the proxy (which is doing topology = hiding) with the overload feature". Additionally, the solution breaks topology hiding feature itself and your j= ustification is that "we haven't agreed requirement to not break this featu= re!". I am sorry, but I don't see why we need any protocol based solution here. It is simple matter operator knowing its network/deployment/nodes and exist= ing features and enabling new feature based on "this" knowledge. And doing = some basic testing/dry run before going live.=20 3GPP or IETF, if we start defining solution assuming that "but the operator= may have forgotten to do this or that", we are adding solutions in our pro= duct which are simply overhead.=20 Finally, we should be looking at the justification to have some solution an= d not add some change just because it is minor. Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, August 20, 2014 9:56 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Nirav, Can you please be more specific about which of the explanations you don't a= gree with? I agree we can't completely ignore the way that Diameter is being used. We should also be avoiding a solution that leaves open the possibility of s= ignificant under utilization of Diameter network resources. We have a stat= ed requirement that the solution must not result in under utilization. I must admit I'm surprised at the response the proposal is getting. It is a= very minor change that makes the protocol more resilient. Steve On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: > Steve, > > I don't agree with your explanations. > > Additionally, we may not have explicit requirement to make DOIC work in t= he face of topology hiding but that does not mean that "DOIC can break any = existing feature - be it topology hiding - and that's fine!". > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:24 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives=20 > analysis > > Nirav, > > Please see my comments inline. > > Steve > > On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >> I agree with Lionel on multiple accounts. >> I don't see any value in alternative 1. In fact, as I had already indica= ted, the alternative 1 breaks one or more of existing feature and hence it = is not a solution by itself. > SRD> The value is that, through a protocol solution, we can make it > possible to prevent a complete shutdown of all traffic through a OHMA. > It might be a small probability, but it is > 0, the impact is significant= and the cost of the proposed protocol solution is extremely small. > > SRD> I'm assuming that the breakage you are talking about is that the > proposal does allow for topology information to leak across operator boun= daries. This is true, however, we do not, however, have a requirement to m= ake DOIC work in the face of topology hiding. Are there other existing fea= tures that you are concerned about? >> Additionally, like any other feature, the operator does not simply enabl= e this feature in their network without considerable planning, lab and fiel= d testing. And this is true for between two operators as well - where the b= igger issue is whether to expose the overload information between two PLMNs= or not. > SRD> We are designing DOIC for Diameter usage in general, not just > 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at l= east for well disciplined operators that have extensive testing as you poin= t out. I don't, however, think we can make that assumption across all uses= of Diameter. That's one of the reasons why we have requirements stating t= hat the solution should not rely on configuration. >> So I don't see the need to have protocol based solution to help operator= debug "what they have forgotten about their network". > SRD> As has been pointed out multiple times, this is not just about=20 > SRD> the > operator's own network. The negative impacts can result from another ope= rator not upgrading their agents to support DOIC. > > SRD> I look at this as a low cost insurance policy. It doesn't hurt > anything to add this small change and it helps prevent would could be a m= ajor outage. >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 >> lionel.morand@orange.com >> Sent: Tuesday, August 19, 2014 8:57 PM >> To: Steve Donovan; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives=20 >> analysis >> >> Hi Steve, >> >> If you decide to deploy a proxy modifying the origin-host, it would be f= or some specific purposes in a given context. If the context has changed, y= ou will have to reconsider the whole mechanism. And it is not only related = to DOIC. >> If not done, this is what I'm calling a bad design: it is not only about= the implementation of the product itself, it is also about how this produc= t is used in the operational network. >> And I don't buy the argument that an operator might have forgotten that = a proxy modifying origin-host would have been deployed in the network befor= e the introduction of DOIC. >> >> About alt 1: >> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-= OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR rep= ort when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between th= e diameter-id in the OC-OLR report and in the Origin-Host AVP. When there = is a difference, the reacting node should report on the condition (event/al= arm). Local policy would determine if the reacting node honors the overloa= d report or ignores the overload report. >> The following question still remain not answered: if the proxy replaces = the origin-host A by origin-host B, the Diameter nodes receiving the answer= s will "see" B as sender of the answer and will use this id when sending ne= w requests with origin-host AVP. So can you remind me how exactly the react= ing node will use the Diameter-id received in the OLR? >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi=20 >> 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >> alternatives analysis >> >> Lionel, >> >> More inline. >> >> Steve >> >> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> See below. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >>> alternatives analysis >>> >>> Lionel, >>> >>> There are two primary reasons that I think option 1 is important: >>> >>> 1) This scenario can result in significant under utilization of resourc= es, to the extreme of completely shutting down all traffic to the servers b= ehind the Origin-Host Munging Agent (OHMA). >>> >>> 2) It gives operates a way to detect the unplanned or forgotten instanc= e of the OHMA. >>> >>> Being able to prevent number 1 is enough reason for me to add the very = small amount of additional protocol machinery we are talking about. >>> >>> [LM] And I disagree. >>> >>> More inline. >>> [LM] same >>> >>> Steve >>> >>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>> Because a a gent modifying the Origin-host can only be a proxy and a p= roxy is by definition compliant with the application supporting the new OLR= -related AVPs, everything else is out of scope of the standardization. >>> SRD> I don't understand this argument. It is perfectly valid for a >>> client or server to advertise support for an application and not also s= upport DOIC. Why do you imply that it would be different for an agent? >>> [LM] A proxy that would modify the origin-host without taking into acco= unt the possible use of this origin-host at the application would be a badl= y-designed proxy and should not be used in operational network. >> SRD2> Consider the following timeline: >> >> Date - Event: >> >> Sometime in 2011 - Operator installs an agent to do topology hiding or l= oad balancing or some other function and the agent modifies the origin-host= AVP as part of its logic. In 2011 this works perfectly well for all appli= cations handled by the agent. >> >> Sometime in 2015 - The IETF publishes the DOIC specification. >> >> Are you asserting that the agent deployed in 2011 was badly designed bec= ause it did not anticipate the DOIC solution published four years later? >>>> Moreover, the real added-value of the addition of the diameter-id in t= he OLR does not seem so clear. >>> SRD> See above. >>> [LM] still unclear >> SRD2> Detection of the fact that an OHMA exists so that something >> intelligent can be done before it results in a total shutdown of the Dia= meter network. >>>> Finally, we have agreed that the basic mechanism proposed in the draft= may not cover all the use cases (existing or future) and can be enhanced i= f required, with or without the need for a IETF standard action. >>> SRD> The reasons so far for deferring functionality was because it=20 >>> SRD> would >>> add risk to the schedule for finishing the core DOIC solution. That is= not the case here. We have a very small change to the specification that = addresses multiple requirements. >>> [LM] is there any clear description of what will be the use of this inf= o by the reacting node? if the proxy replaces the origin-host A by origin-h= ost B, the Diameter nodes receiving the answers will "see" B as sender of t= he answer and will use this id when sending new requests with origin-host A= VP. So can you remind me how exactly the reacting node will use the Diamete= r-id received in the OLR? >> SRD> Scroll down an look at the details behind alternative 1. >>>> For all these reasons, I would recommend not to add this Diameter-id i= n the OLR and to assume that the Origin-host is not changed by agent in the= path of the Diameter messages. Some extra text could also be added to clar= ify that proxies modifying the Origin-host would have to be upgraded to man= age consistently the OLR received in Diameter application messages. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 >>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent=20 >>>> alternatives analysis >>>> >>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>> >>>> As Nirav pointed out, it has the potential to leak topology informatio= n past a topology hiding proxy. (Unless we can come up with some attributio= n scheme that is not based on Diameter Identity or IP Address.) It may be r= easonable, to do this, but we would need some guidance to warn operators th= at this may happen if they enable DOIC across a non-supporting, topology-hi= ding proxy. It would become the operator's choice to decide which is more i= mportant. >>>> >>>> The part I find unsatisfying, is what would happen if you had some pat= hs that supported DOIC (or did not do topology hiding), and some paths that= don't support DOIC also do topology hiding. This could become a pretty big= administrative hit, and violates the spirit and letter of our requirement = to avoid adding lots of configuration work. >>>> >>>> OTOH, if we had a mechanism where servers could detect the existence o= f a non-DOIC, topology-hiding proxy, this could be at least partially autom= ated. I can think of multiple ways we could make it possible to tell if an = immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>> >>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: >>>> >>>>> All, >>>>> >>>>> My recommendation on this alternative 1 as it give operators the abil= ity to discover when there is an issue associated with "Origin-Host Munging= " agents. The operators can then take any administrative action necessary = to fix the issue. It is also a more general solution that does not rely on= one industries interop procedures. >>>>> >>>>> If we can get agreement on this then we can start making progress on = the remainder of the document. >>>>> >>>>> Steve >>>>> >>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>> Are there other thoughts on the pros and cons of the three proposals= for resolution of issue #66? >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> The issue with pre-DOIC agents changing origin-host was been discu= ssed in this thread: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>> >>>>>>>> One example of the impact of the issue is defined in this message: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>> >>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-= OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR rep= ort when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between th= e diameter-id in the OC-OLR report and in the Origin-Host AVP. When there = is a difference, the reacting node should report on the condition (event/al= arm). Local policy would determine if the reacting node honors the overloa= d report or ignores the overload report. >>>>>>> I think the last entry is worth further discussion, but it's probab= ly more important to make a high level decision first. But, at risk of gett= ing ahead of myself: I have trouble imagining a situation where honoring th= e overload report will be harmful, since if there is an intervening OHMA, t= he reacting node will not likely have any host-routed requests to the diame= ter-id from the OLR. OTOH, I have trouble imagining where honoring the repo= rt would be useful, for the same reason. >>>>>>> >>>>>>>> 2) Configuration in operator's networks to turn off origin-host mu= nging behavior until the agent is upgraded to support DOIC. >>>>>>>> >>>>>>>> 3) Configuration of reporting nodes to not send overload reports, = either universally or for transactions that cross the origin-host munging a= gent. >>>>>>>> >>>>>>>> I've compiled a starting point for a pros and cons analysis of the= three approaches. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> --------- >>>>>>>> >>>>>>>> Option 1 Pros: >>>>>>>> ------------ >>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC o= rigin-host-munging agent in the path of a transaction. >>>>>>>> - Gives operators ability to manage the under utilization issue ca= used by the non-DOIC agent. >>>>>>>> - Gives operators the ability to keep features requiring origin-ho= st munging turned on while DOIC is rolled out. >>>>>>>> - Leaves the determination of which action to take in this scenari= o (honor or ignore overload reports) to operator policy. >>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of co= nfiguration required. >>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a= single node overload on the traffic handled by other nodes in the network. >>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of o= verload in a mixed DOIC environment on the overall capacity of the network. >>>>>>> Specifically, it complies with the MUST NOT make things worth claus= e, but does not comply with the SHOULD reduce overload clause. >>>>>>> >>>>>>>> Option 1 Cons: >>>>>>>> ------------- >>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>> - Does not completely fix the effects of non-DOIC agent on=20 >>>>>>>> overload control >>>>>>> One additional con is that, if the OHMA is there for the purposes o= f true topology hiding, the identity in the OLR may leak topology informati= on. >>>>>>> >>>>>>>> Option 2 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Does the best job of three alternatives in allowing for=20 >>>>>>>> management of overload conditions >>>>>>>> >>>>>>>> Option 2 Cons: >>>>>>>> ------------ >>>>>>>> - Requires the operator to lose any functionality enabled by=20 >>>>>>>> the non-DOIC agent until all agents have been upgraded to=20 >>>>>>>> support DOIC >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - There is not way to determine if all non-DOIC origin-host mungin= g behavior has been turned off until an overload event happens, with potent= ial to have significant negative effects until the offending agent can be f= ound and the behavior turned off. >>>>>>>> - Not always possible, as operator doesn't always have control ove= r non-DOIC agent as it might be in another operators network. Proposal to a= ddress this through interop agreements but while this might work in 3GPP sc= enarios, not all Diameter deployments are 3GPP driven. >>>>>>> Since you mentioned the 7068 requirements in the cons for option=20 >>>>>>> 1, it makes sense to mention them for others. This one misses on=20 >>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a=20 >>>>>>> requirement about not interfering with existing network features. >>>>>>> If we had that, Option 2 would not comply.) >>>>>>> >>>>>>>> Option 3 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Gives operators the ability to keep features requiring origin-ho= st munging turned on while DOIC is rolled out. >>>>>>> For very limited definitions of "rolled out." >>>>>>> >>>>>>>> Option 3 Cons: >>>>>>>> ------------ >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - Likely requires extra development in the reporting node that=20 >>>>>>>> would not otherwise be needed (ability to limit where overload=20 >>>>>>>> reports are sent) >>>>>>>> - Not necessarily easy to determine in advance where which=20 >>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>> - Limits ability of operator to fully control overload >>>>>>>> >>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a si= milar way as option 1. Partially misses 34. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> ___________________________________________________________________ >>>> _ _ _ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles 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=20 >>>> privileged information that may be protected by law; they should not b= e 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. >>>> >>>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >> >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Wed Aug 20 09:48:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85D1A03F9 for ; Wed, 20 Aug 2014 09:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQHqvx1ZmGsG for ; Wed, 20 Aug 2014 09:48:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312FE1A045B for ; Wed, 20 Aug 2014 09:48:17 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 01F9D1B8324; Wed, 20 Aug 2014 18:48:15 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id CCE6B158059; Wed, 20 Aug 2014 18:48:14 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 18:48:14 +0200 From: To: Steve Donovan , Ben Campbell , "Nirav Salot (nsalot)" Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPu7xAixeXE7DuBE6VeIfag6SAwpvYCiZwgADa4wCAAJ/ugIAAAYCAgAAHUoCAAATdgIAAIvMM Date: Wed, 20 Aug 2014 16:48:13 +0000 Message-ID: <24045_1408553294_53F4D14E_24045_12507_1_9nidawx9i9ng2cwva6varu4m.1408553290876@email.android.com> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.20.122118 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FUNCyNCjgoeq-YUN8_1Qg7ncwuc Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 16:48:23 -0000 I totally share the clear explanation given by Nirav. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Nirav Salot (nsalot) a =E9crit ---- Steve, You are proposing a change (minor or not) for a problem which does not exis= t (in my view at least) since the use case is - The operator has enabled overload feature in his network and has not upgr= aded one of the proxy - The operator has "forgotten" that the proxy which is not upgraded is doin= g topology hiding Or between two operators, they have entered into the agreement to share the= overload reports but have not bothered to upgrade all of their nodes and n= ot done any basic testing before activating the overload feature. So we are defining the solution for the above use cases. And the solution y= ou are suggesting it results in - The client ignoring the overload report and thus the operator finds out t= hat "he has forgotten to upgrade one of the proxy (which is doing topology = hiding) with the overload feature". Additionally, the solution breaks topology hiding feature itself and your j= ustification is that "we haven't agreed requirement to not break this featu= re!". I am sorry, but I don't see why we need any protocol based solution here. It is simple matter operator knowing its network/deployment/nodes and exist= ing features and enabling new feature based on "this" knowledge. And doing = some basic testing/dry run before going live. 3GPP or IETF, if we start defining solution assuming that "but the operator= may have forgotten to do this or that", we are adding solutions in our pro= duct which are simply overhead. Finally, we should be looking at the justification to have some solution an= d not add some change just because it is minor. Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Wednesday, August 20, 2014 9:56 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Nirav, Can you please be more specific about which of the explanations you don't a= gree with? I agree we can't completely ignore the way that Diameter is being used. We should also be avoiding a solution that leaves open the possibility of s= ignificant under utilization of Diameter network resources. We have a stat= ed requirement that the solution must not result in under utilization. I must admit I'm surprised at the response the proposal is getting. It is a= very minor change that makes the protocol more resilient. Steve On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: > Steve, > > I don't agree with your explanations. > > Additionally, we may not have explicit requirement to make DOIC work in t= he face of topology hiding but that does not mean that "DOIC can break any = existing feature - be it topology hiding - and that's fine!". > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:24 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives > analysis > > Nirav, > > Please see my comments inline. > > Steve > > On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >> I agree with Lionel on multiple accounts. >> I don't see any value in alternative 1. In fact, as I had already indica= ted, the alternative 1 breaks one or more of existing feature and hence it = is not a solution by itself. > SRD> The value is that, through a protocol solution, we can make it > possible to prevent a complete shutdown of all traffic through a OHMA. > It might be a small probability, but it is > 0, the impact is significant= and the cost of the proposed protocol solution is extremely small. > > SRD> I'm assuming that the breakage you are talking about is that the > proposal does allow for topology information to leak across operator boun= daries. This is true, however, we do not, however, have a requirement to m= ake DOIC work in the face of topology hiding. Are there other existing fea= tures that you are concerned about? >> Additionally, like any other feature, the operator does not simply enabl= e this feature in their network without considerable planning, lab and fiel= d testing. And this is true for between two operators as well - where the b= igger issue is whether to expose the overload information between two PLMNs= or not. > SRD> We are designing DOIC for Diameter usage in general, not just > 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at l= east for well disciplined operators that have extensive testing as you poin= t out. I don't, however, think we can make that assumption across all uses= of Diameter. That's one of the reasons why we have requirements stating t= hat the solution should not rely on configuration. >> So I don't see the need to have protocol based solution to help operator= debug "what they have forgotten about their network". > SRD> As has been pointed out multiple times, this is not just about > SRD> the > operator's own network. The negative impacts can result from another ope= rator not upgrading their agents to support DOIC. > > SRD> I look at this as a low cost insurance policy. It doesn't hurt > anything to add this small change and it helps prevent would could be a m= ajor outage. >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >> lionel.morand@orange.com >> Sent: Tuesday, August 19, 2014 8:57 PM >> To: Steve Donovan; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> Hi Steve, >> >> If you decide to deploy a proxy modifying the origin-host, it would be f= or some specific purposes in a given context. If the context has changed, y= ou will have to reconsider the whole mechanism. And it is not only related = to DOIC. >> If not done, this is what I'm calling a bad design: it is not only about= the implementation of the product itself, it is also about how this produc= t is used in the operational network. >> And I don't buy the argument that an operator might have forgotten that = a proxy modifying origin-host would have been deployed in the network befor= e the introduction of DOIC. >> >> About alt 1: >> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-= OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR rep= ort when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between th= e diameter-id in the OC-OLR report and in the Origin-Host AVP. When there = is a difference, the reacting node should report on the condition (event/al= arm). Local policy would determine if the reacting node honors the overloa= d report or ignores the overload report. >> The following question still remain not answered: if the proxy replaces = the origin-host A by origin-host B, the Diameter nodes receiving the answer= s will "see" B as sender of the answer and will use this id when sending ne= w requests with origin-host AVP. So can you remind me how exactly the react= ing node will use the Diameter-id received in the OLR? >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >> 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >> alternatives analysis >> >> Lionel, >> >> More inline. >> >> Steve >> >> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> See below. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> There are two primary reasons that I think option 1 is important: >>> >>> 1) This scenario can result in significant under utilization of resourc= es, to the extreme of completely shutting down all traffic to the servers b= ehind the Origin-Host Munging Agent (OHMA). >>> >>> 2) It gives operates a way to detect the unplanned or forgotten instanc= e of the OHMA. >>> >>> Being able to prevent number 1 is enough reason for me to add the very = small amount of additional protocol machinery we are talking about. >>> >>> [LM] And I disagree. >>> >>> More inline. >>> [LM] same >>> >>> Steve >>> >>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>> Because a a gent modifying the Origin-host can only be a proxy and a p= roxy is by definition compliant with the application supporting the new OLR= -related AVPs, everything else is out of scope of the standardization. >>> SRD> I don't understand this argument. It is perfectly valid for a >>> client or server to advertise support for an application and not also s= upport DOIC. Why do you imply that it would be different for an agent? >>> [LM] A proxy that would modify the origin-host without taking into acco= unt the possible use of this origin-host at the application would be a badl= y-designed proxy and should not be used in operational network. >> SRD2> Consider the following timeline: >> >> Date - Event: >> >> Sometime in 2011 - Operator installs an agent to do topology hiding or l= oad balancing or some other function and the agent modifies the origin-host= AVP as part of its logic. In 2011 this works perfectly well for all appli= cations handled by the agent. >> >> Sometime in 2015 - The IETF publishes the DOIC specification. >> >> Are you asserting that the agent deployed in 2011 was badly designed bec= ause it did not anticipate the DOIC solution published four years later? >>>> Moreover, the real added-value of the addition of the diameter-id in t= he OLR does not seem so clear. >>> SRD> See above. >>> [LM] still unclear >> SRD2> Detection of the fact that an OHMA exists so that something >> intelligent can be done before it results in a total shutdown of the Dia= meter network. >>>> Finally, we have agreed that the basic mechanism proposed in the draft= may not cover all the use cases (existing or future) and can be enhanced i= f required, with or without the need for a IETF standard action. >>> SRD> The reasons so far for deferring functionality was because it >>> SRD> would >>> add risk to the schedule for finishing the core DOIC solution. That is= not the case here. We have a very small change to the specification that = addresses multiple requirements. >>> [LM] is there any clear description of what will be the use of this inf= o by the reacting node? if the proxy replaces the origin-host A by origin-h= ost B, the Diameter nodes receiving the answers will "see" B as sender of t= he answer and will use this id when sending new requests with origin-host A= VP. So can you remind me how exactly the reacting node will use the Diamete= r-id received in the OLR? >> SRD> Scroll down an look at the details behind alternative 1. >>>> For all these reasons, I would recommend not to add this Diameter-id i= n the OLR and to assume that the Origin-host is not changed by agent in the= path of the Diameter messages. Some extra text could also be added to clar= ify that proxies modifying the Origin-host would have to be upgraded to man= age consistently the OLR received in Diameter application messages. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>> >>>> As Nirav pointed out, it has the potential to leak topology informatio= n past a topology hiding proxy. (Unless we can come up with some attributio= n scheme that is not based on Diameter Identity or IP Address.) It may be r= easonable, to do this, but we would need some guidance to warn operators th= at this may happen if they enable DOIC across a non-supporting, topology-hi= ding proxy. It would become the operator's choice to decide which is more i= mportant. >>>> >>>> The part I find unsatisfying, is what would happen if you had some pat= hs that supported DOIC (or did not do topology hiding), and some paths that= don't support DOIC also do topology hiding. This could become a pretty big= administrative hit, and violates the spirit and letter of our requirement = to avoid adding lots of configuration work. >>>> >>>> OTOH, if we had a mechanism where servers could detect the existence o= f a non-DOIC, topology-hiding proxy, this could be at least partially autom= ated. I can think of multiple ways we could make it possible to tell if an = immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>> >>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: >>>> >>>>> All, >>>>> >>>>> My recommendation on this alternative 1 as it give operators the abil= ity to discover when there is an issue associated with "Origin-Host Munging= " agents. The operators can then take any administrative action necessary = to fix the issue. It is also a more general solution that does not rely on= one industries interop procedures. >>>>> >>>>> If we can get agreement on this then we can start making progress on = the remainder of the document. >>>>> >>>>> Steve >>>>> >>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>> Are there other thoughts on the pros and cons of the three proposals= for resolution of issue #66? >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> The issue with pre-DOIC agents changing origin-host was been discu= ssed in this thread: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>> >>>>>>>> One example of the impact of the issue is defined in this message: >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>> >>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>> >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the OC-= OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR rep= ort when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between th= e diameter-id in the OC-OLR report and in the Origin-Host AVP. When there = is a difference, the reacting node should report on the condition (event/al= arm). Local policy would determine if the reacting node honors the overloa= d report or ignores the overload report. >>>>>>> I think the last entry is worth further discussion, but it's probab= ly more important to make a high level decision first. But, at risk of gett= ing ahead of myself: I have trouble imagining a situation where honoring th= e overload report will be harmful, since if there is an intervening OHMA, t= he reacting node will not likely have any host-routed requests to the diame= ter-id from the OLR. OTOH, I have trouble imagining where honoring the repo= rt would be useful, for the same reason. >>>>>>> >>>>>>>> 2) Configuration in operator's networks to turn off origin-host mu= nging behavior until the agent is upgraded to support DOIC. >>>>>>>> >>>>>>>> 3) Configuration of reporting nodes to not send overload reports, = either universally or for transactions that cross the origin-host munging a= gent. >>>>>>>> >>>>>>>> I've compiled a starting point for a pros and cons analysis of the= three approaches. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> --------- >>>>>>>> >>>>>>>> Option 1 Pros: >>>>>>>> ------------ >>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC o= rigin-host-munging agent in the path of a transaction. >>>>>>>> - Gives operators ability to manage the under utilization issue ca= used by the non-DOIC agent. >>>>>>>> - Gives operators the ability to keep features requiring origin-ho= st munging turned on while DOIC is rolled out. >>>>>>>> - Leaves the determination of which action to take in this scenari= o (honor or ignore overload reports) to operator policy. >>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of co= nfiguration required. >>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a= single node overload on the traffic handled by other nodes in the network. >>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of o= verload in a mixed DOIC environment on the overall capacity of the network. >>>>>>> Specifically, it complies with the MUST NOT make things worth claus= e, but does not comply with the SHOULD reduce overload clause. >>>>>>> >>>>>>>> Option 1 Cons: >>>>>>>> ------------- >>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>> overload control >>>>>>> One additional con is that, if the OHMA is there for the purposes o= f true topology hiding, the identity in the OLR may leak topology informati= on. >>>>>>> >>>>>>>> Option 2 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>> management of overload conditions >>>>>>>> >>>>>>>> Option 2 Cons: >>>>>>>> ------------ >>>>>>>> - Requires the operator to lose any functionality enabled by >>>>>>>> the non-DOIC agent until all agents have been upgraded to >>>>>>>> support DOIC >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - There is not way to determine if all non-DOIC origin-host mungin= g behavior has been turned off until an overload event happens, with potent= ial to have significant negative effects until the offending agent can be f= ound and the behavior turned off. >>>>>>>> - Not always possible, as operator doesn't always have control ove= r non-DOIC agent as it might be in another operators network. Proposal to a= ddress this through interop agreements but while this might work in 3GPP sc= enarios, not all Diameter deployments are 3GPP driven. >>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>> requirement about not interfering with existing network features. >>>>>>> If we had that, Option 2 would not comply.) >>>>>>> >>>>>>>> Option 3 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Gives operators the ability to keep features requiring origin-ho= st munging turned on while DOIC is rolled out. >>>>>>> For very limited definitions of "rolled out." >>>>>>> >>>>>>>> Option 3 Cons: >>>>>>>> ------------ >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>> reports are sent) >>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>> - Limits ability of operator to fully control overload >>>>>>>> >>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a si= milar way as option 1. Partially misses 34. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> ___________________________________________________________________ >>>> _ _ _ ___________________________________________________ >>>> >>>> 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 detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles 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 b= e 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. >>>> >>>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> 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 detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >> >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Aug 20 14:18:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B684E1A02EA for ; Wed, 20 Aug 2014 14:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOm5XextUhTM for ; Wed, 20 Aug 2014 14:17:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD7D1A8776 for ; Wed, 20 Aug 2014 14:17:58 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7KLHp3R076086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 16:17:52 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Wed, 20 Aug 2014 16:17:50 -0500 X-Mao-Original-Outgoing-Id: 430262270.702993-974306af31f739b7ce13c1aa59d291b3 Content-Transfer-Encoding: quoted-printable Message-Id: <92B42AB1-B7D7-48E7-B222-2A474BF975EC@nostrum.com> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> To: Dave Dolson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OAjAW4ojecpxhfszATXo_Iy91yY Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 21:18:03 -0000 Hi Dave, I think that could help with one of the use cases for attribution--which = was to determine if a stream of overload reports are coming from the = same server. I'm not sure if it would help for the case of sending = host-reports across a non-DOIC proxy that munges origin-host, since the = reacting node needs to match the identity of the overloaded host to = values used in Destination-Host in future requests. I guess it might be = possible to use it to allow reacting nodes to infer that the the = origin-host field in the answer carrying the report has been modified, = and that the report must be treated as invalid. (I haven't wrapped my = brain around that one yet.) A unique key would have the advantage of not leaking IP addresses or = Diameter identities across a topology-hiding proxy. It would still let = downstream nodes infer the number of servers behind such a = topology-hiding proxy, by observing the number of unique key values. I = suspect sometimes that would be okay and sometimes it would not. /Ben On Aug 20, 2014, at 11:17 AM, Dave Dolson wrote: > It seems to me that this stale-mate may be addressed by observing that = the host name has been introduced to distinguish between multiple = reports, and that any unique key would allow this. >=20 > Would it be acceptable to make the field any arbitrary unique key = rather than the host name? > (Host name is a special case of arbitrary unique key) >=20 > Then a receiver would recognize that reports are coming from multiple = sources without any reveal of actual host names. >=20 > Those concerned about AVP size could use 4-byte discriminators; those = concerned about global uniqueness could use the host name. >=20 >=20 > -Dave. >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Wednesday, August 20, 2014 11:54 AM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives = analysis >=20 > Nirav, >=20 > Please see my comments inline. >=20 > Steve >=20 > On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >> I agree with Lionel on multiple accounts. >> I don't see any value in alternative 1. In fact, as I had already = indicated, the alternative 1 breaks one or more of existing feature and = hence it is not a solution by itself. > SRD> The value is that, through a protocol solution, we can make it=20 > possible to prevent a complete shutdown of all traffic through a OHMA. = =20 > It might be a small probability, but it is > 0, the impact is=20 > significant and the cost of the proposed protocol solution is = extremely=20 > small. >=20 > SRD> I'm assuming that the breakage you are talking about is that the=20= > proposal does allow for topology information to leak across operator=20= > boundaries. This is true, however, we do not, however, have a=20 > requirement to make DOIC work in the face of topology hiding. Are = there=20 > other existing features that you are concerned about? >>=20 >> Additionally, like any other feature, the operator does not simply = enable this feature in their network without considerable planning, lab = and field testing. And this is true for between two operators as well - = where the bigger issue is whether to expose the overload information = between two PLMNs or not. > SRD> We are designing DOIC for Diameter usage in general, not just=20 > 3GPP. I agree that this scenario is unlikely in a 3GPP environment, = at=20 > least for well disciplined operators that have extensive testing as = you=20 > point out. I don't, however, think we can make that assumption across=20= > all uses of Diameter. That's one of the reasons why we have=20 > requirements stating that the solution should not rely on = configuration. >> So I don't see the need to have protocol based solution to help = operator debug "what they have forgotten about their network". > SRD> As has been pointed out multiple times, this is not just about = the=20 > operator's own network. The negative impacts can result from another=20= > operator not upgrading their agents to support DOIC. >=20 > SRD> I look at this as a low cost insurance policy. It doesn't hurt=20= > anything to add this small change and it helps prevent would could be = a=20 > major outage. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com >> Sent: Tuesday, August 19, 2014 8:57 PM >> To: Steve Donovan; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives = analysis >>=20 >> Hi Steve, >>=20 >> If you decide to deploy a proxy modifying the origin-host, it would = be for some specific purposes in a given context. If the context has = changed, you will have to reconsider the whole mechanism. And it is not = only related to DOIC. >> If not done, this is what I'm calling a bad design: it is not only = about the implementation of the product itself, it is also about how = this product is used in the operational network. >> And I don't buy the argument that an operator might have forgotten = that a proxy modifying origin-host would have been deployed in the = network before the introduction of DOIC. >>=20 >> About alt 1: >>=20 >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the = OC-OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR = report when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When = there is a difference, the reacting node should report on the condition = (event/alarm). Local policy would determine if the reacting node honors = the overload report or ignores the overload report. >> The following question still remain not answered: if the proxy = replaces the origin-host A by origin-host B, the Diameter nodes = receiving the answers will "see" B as sender of the answer and will use = this id when sending new requests with origin-host AVP. So can you = remind me how exactly the reacting node will use the Diameter-id = received in the OLR? >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi = 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : = dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent = alternatives analysis >>=20 >> Lionel, >>=20 >> More inline. >>=20 >> Steve >>=20 >> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>>=20 >>> See below. >>>=20 >>> Regards, >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : = mardi 19 >>> ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>>=20 >>> Lionel, >>>=20 >>> There are two primary reasons that I think option 1 is important: >>>=20 >>> 1) This scenario can result in significant under utilization of = resources, to the extreme of completely shutting down all traffic to the = servers behind the Origin-Host Munging Agent (OHMA). >>>=20 >>> 2) It gives operates a way to detect the unplanned or forgotten = instance of the OHMA. >>>=20 >>> Being able to prevent number 1 is enough reason for me to add the = very small amount of additional protocol machinery we are talking about. >>>=20 >>> [LM] And I disagree. >>>=20 >>> More inline. >>> [LM] same >>>=20 >>> Steve >>>=20 >>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>> Because a a gent modifying the Origin-host can only be a proxy and = a proxy is by definition compliant with the application supporting the = new OLR-related AVPs, everything else is out of scope of the = standardization. >>> SRD> I don't understand this argument. It is perfectly valid for a >>> client or server to advertise support for an application and not = also support DOIC. Why do you imply that it would be different for an = agent? >>> [LM] A proxy that would modify the origin-host without taking into = account the possible use of this origin-host at the application would be = a badly-designed proxy and should not be used in operational network. >> SRD2> Consider the following timeline: >>=20 >> Date - Event: >>=20 >> Sometime in 2011 - Operator installs an agent to do topology hiding = or load balancing or some other function and the agent modifies the = origin-host AVP as part of its logic. In 2011 this works perfectly well = for all applications handled by the agent. >>=20 >> Sometime in 2015 - The IETF publishes the DOIC specification. >>=20 >> Are you asserting that the agent deployed in 2011 was badly designed = because it did not anticipate the DOIC solution published four years = later? >>>> Moreover, the real added-value of the addition of the diameter-id = in the OLR does not seem so clear. >>> SRD> See above. >>> [LM] still unclear >> SRD2> Detection of the fact that an OHMA exists so that something >> intelligent can be done before it results in a total shutdown of the = Diameter network. >>>> Finally, we have agreed that the basic mechanism proposed in the = draft may not cover all the use cases (existing or future) and can be = enhanced if required, with or without the need for a IETF standard = action. >>> SRD> The reasons so far for deferring functionality was because it >>> SRD> would >>> add risk to the schedule for finishing the core DOIC solution. That = is not the case here. We have a very small change to the specification = that addresses multiple requirements. >>> [LM] is there any clear description of what will be the use of this = info by the reacting node? if the proxy replaces the origin-host A by = origin-host B, the Diameter nodes receiving the answers will "see" B as = sender of the answer and will use this id when sending new requests with = origin-host AVP. So can you remind me how exactly the reacting node will = use the Diameter-id received in the OLR? >> SRD> Scroll down an look at the details behind alternative 1. >>>> For all these reasons, I would recommend not to add this = Diameter-id in the OLR and to assume that the Origin-host is not changed = by agent in the path of the Diameter messages. Some extra text could = also be added to clarify that proxies modifying the Origin-host would = have to be upgraded to manage consistently the OLR received in Diameter = application messages. >>>>=20 >>>> Regards, >>>>=20 >>>> Lionel >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>>=20 >>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>>=20 >>>> As Nirav pointed out, it has the potential to leak topology = information past a topology hiding proxy. (Unless we can come up with = some attribution scheme that is not based on Diameter Identity or IP = Address.) It may be reasonable, to do this, but we would need some = guidance to warn operators that this may happen if they enable DOIC = across a non-supporting, topology-hiding proxy. It would become the = operator's choice to decide which is more important. >>>>=20 >>>> The part I find unsatisfying, is what would happen if you had some = paths that supported DOIC (or did not do topology hiding), and some = paths that don't support DOIC also do topology hiding. This could become = a pretty big administrative hit, and violates the spirit and letter of = our requirement to avoid adding lots of configuration work. >>>>=20 >>>> OTOH, if we had a mechanism where servers could detect the = existence of a non-DOIC, topology-hiding proxy, this could be at least = partially automated. I can think of multiple ways we could make it = possible to tell if an immediate peer supports DOIC, but not so much for = non-adjacent nodes. >>>>=20 >>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> My recommendation on this alternative 1 as it give operators the = ability to discover when there is an issue associated with "Origin-Host = Munging" agents. The operators can then take any administrative action = necessary to fix the issue. It is also a more general solution that = does not rely on one industries interop procedures. >>>>>=20 >>>>> If we can get agreement on this then we can start making progress = on the remainder of the document. >>>>>=20 >>>>> Steve >>>>>=20 >>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>> Are there other thoughts on the pros and cons of the three = proposals for resolution of issue #66? >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan = wrote: >>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> The issue with pre-DOIC agents changing origin-host was been = discussed in this thread: >>>>>>>>=20 >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>>=20 >>>>>>>> One example of the impact of the issue is defined in this = message: >>>>>>>>=20 >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>>=20 >>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>>=20 >>>>>>>> 1) Attribution of overload reports. >>>>>>>> - Add diameter-id of the node that is overloaded into the = OC-OLR AVP. >>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR = report when applying abatement algorithm logic. >>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When = there is a difference, the reacting node should report on the condition = (event/alarm). Local policy would determine if the reacting node honors = the overload report or ignores the overload report. >>>>>>> I think the last entry is worth further discussion, but it's = probably more important to make a high level decision first. But, at = risk of getting ahead of myself: I have trouble imagining a situation = where honoring the overload report will be harmful, since if there is an = intervening OHMA, the reacting node will not likely have any host-routed = requests to the diameter-id from the OLR. OTOH, I have trouble imagining = where honoring the report would be useful, for the same reason. >>>>>>>=20 >>>>>>>> 2) Configuration in operator's networks to turn off origin-host = munging behavior until the agent is upgraded to support DOIC. >>>>>>>>=20 >>>>>>>> 3) Configuration of reporting nodes to not send overload = reports, either universally or for transactions that cross the = origin-host munging agent. >>>>>>>>=20 >>>>>>>> I've compiled a starting point for a pros and cons analysis of = the three approaches. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Steve >>>>>>>>=20 >>>>>>>> --------- >>>>>>>>=20 >>>>>>>> Option 1 Pros: >>>>>>>> ------------ >>>>>>>> - Gives operators a mechanism to detect when there is a = non-DOIC origin-host-munging agent in the path of a transaction. >>>>>>>> - Gives operators ability to manage the under utilization issue = caused by the non-DOIC agent. >>>>>>>> - Gives operators the ability to keep features requiring = origin-host munging turned on while DOIC is rolled out. >>>>>>>> - Leaves the determination of which action to take in this = scenario (honor or ignore overload reports) to operator policy. >>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of = configuration required. >>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact = of a single node overload on the traffic handled by other nodes in the = network. >>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact = of overload in a mixed DOIC environment on the overall capacity of the = network. >>>>>>> Specifically, it complies with the MUST NOT make things worth = clause, but does not comply with the SHOULD reduce overload clause. >>>>>>>=20 >>>>>>>> Option 1 Cons: >>>>>>>> ------------- >>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>> overload control >>>>>>> One additional con is that, if the OHMA is there for the = purposes of true topology hiding, the identity in the OLR may leak = topology information. >>>>>>>=20 >>>>>>>> Option 2 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>> management of overload conditions >>>>>>>>=20 >>>>>>>> Option 2 Cons: >>>>>>>> ------------ >>>>>>>> - Requires the operator to lose any functionality enabled by = the >>>>>>>> non-DOIC agent until all agents have been upgraded to support >>>>>>>> DOIC >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - There is not way to determine if all non-DOIC origin-host = munging behavior has been turned off until an overload event happens, = with potential to have significant negative effects until the offending = agent can be found and the behavior turned off. >>>>>>>> - Not always possible, as operator doesn't always have control = over non-DOIC agent as it might be in another operators network. = Proposal to address this through interop agreements but while this might = work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>> requirement about not interfering with existing network = features. >>>>>>> If we had that, Option 2 would not comply.) >>>>>>>=20 >>>>>>>> Option 3 Pros: >>>>>>>> ------------ >>>>>>>> - Does not require additional protocol machinery >>>>>>>> - Gives operators the ability to keep features requiring = origin-host munging turned on while DOIC is rolled out. >>>>>>> For very limited definitions of "rolled out." >>>>>>>=20 >>>>>>>> Option 3 Cons: >>>>>>>> ------------ >>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>> reports are sent) >>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>> - Limits ability of operator to fully control overload >>>>>>>>=20 >>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a = similar way as option 1. Partially misses 34. >>>>>>>=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 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>> = _____________________________________________________________________ >>>> _ ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=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 nobody Wed Aug 20 14:44:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625291A6F0C for ; Wed, 20 Aug 2014 14:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTXZrWZcHGbM for ; Wed, 20 Aug 2014 14:44:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD251A6EFB for ; Wed, 20 Aug 2014 14:44:55 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7KLipxA078355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 16:44:52 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Wed, 20 Aug 2014 16:44:50 -0500 X-Mao-Original-Outgoing-Id: 430263890.783964-426d35420dbd9cb6a1317d396a31dbf8 Content-Transfer-Encoding: quoted-printable Message-Id: <1C418D2E-A120-4A24-9134-97906937E170@nostrum.com> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4EBwDJ1TXSR_0djyKnwYHeJjzJw Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 21:44:57 -0000 I'm a little confused by this discussion. We have a published DIME = consensus document of DIME (RFC 7068) that has requirements that matter = here, but the discussion seems content to ignore them.=20 In particular, the following quoted requirements bear on this = discussion. > REQ 6: The solution designers SHOULD seek to minimize the amount = of > new configuration required in order to work. For example, = it > is better to allow peers to advertise or negotiate support > for the solution, rather than to require that this = knowledge > be configured at each node. >=20 [...] > REQ 16: The solution is likely to be deployed incrementally. The > solution MUST support a mixed environment where some, but = not > all, nodes implement it. >=20 > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. >=20 More inline: On Aug 20, 2014, at 11:43 AM, Nirav Salot (nsalot) = wrote: > Steve, >=20 > You are proposing a change (minor or not) for a problem which does not = exist (in my view at least) since the use case is > - The operator has enabled overload feature in his network and has not = upgraded one of the proxy > - The operator has "forgotten" that the proxy which is not upgraded is = doing topology hiding Steve is proposing a change to allow incremental deployment without = breaking things (Req 16, and first part of Req 17). In this case, the = incremental deployment is to allow at least some DOIC function, in spite = of a legacy proxy. I believe these requirements require us to at least = attempt to solve the problem. If we can't come up with a solution, we = should document why, and try to keep our non-compliance as narrow as = possible. (This is significantly different from saying that the problem = does not need to be solved.) >=20 > Or between two operators, they have entered into the agreement to = share the overload reports but have not bothered to upgrade all of their = nodes and not done any basic testing before activating the overload = feature.=20 >=20 > So we are defining the solution for the above use cases. And the = solution you are suggesting it results in > - The client ignoring the overload report and thus the operator finds = out that "he has forgotten to upgrade one of the proxy (which is doing = topology hiding) with the overload feature". >=20 > Additionally, the solution breaks topology hiding feature itself and = your justification is that "we haven't agreed requirement to not break = this feature!". This is the one problem I see with the current proposal. I'd like to see = comments from some of the carriers about whether it's a show stopper. We = should also wrack our brains for a solution that does not have this = problem. (Thanks to Dave for taking a shot at that--it would be good to = see other thoughts there.) I note that topology-hiding for it's own sake. is not the only use case = for which proxies munge origin-host in answers. There are other cases = (for example, having the proxy completely take over responsibility for = request routing), where this leakage is not a problem. You may recall = all the early discussions about server front ends (SFEs), where they = _always_ did origin-host munging, but only sometimes did full-blown = topology hiding. This is not theoretical. Such proxies exist in real deployments today. >=20 > I am sorry, but I don't see why we need any protocol based solution = here. > It is simple matter operator knowing its network/deployment/nodes and = existing features and enabling new feature based on "this" knowledge. = And doing some basic testing/dry run before going live.=20 > 3GPP or IETF, if we start defining solution assuming that "but the = operator may have forgotten to do this or that", we are adding solutions = in our product which are simply overhead.=20 You seem to be ignoring Req 6. Also, while the idea that you need to = test everything out in advance may make sense from a 3GPP perspective, = it doesn't from an IETF perspective, where we have to worry about things = like dynamic discovery (which makes Req 5 also relevant.) If you use = dynamic peer discovery, you can't know in advance the features of every = node you may talk to (or across.) >=20 > Finally, we should be looking at the justification to have some = solution and not add some change just because it is minor. Again, the quoted requirements are represent existing consensus. = Certainly we can change consensus--but doing so requires a consensus to = do so. If on the other hand, people think these requirements do not apply to = the problem at hand, they can argue that. But if people have argued that = so far, I've missed it. From nobody Wed Aug 20 15:21:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468921A8947 for ; Wed, 20 Aug 2014 15:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZN1UiJaIAfN for ; Wed, 20 Aug 2014 15:21:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF411A8935 for ; Wed, 20 Aug 2014 15:21:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C9B9B3244C6; Thu, 21 Aug 2014 00:21:48 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A7F50238048; Thu, 21 Aug 2014 00:21:48 +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.03.0195.001; Thu, 21 Aug 2014 00:21:48 +0200 From: To: "Nirav Salot (nsalot)" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPu7xAixeXE7DuBE6VeIfag6SAwpvYCiZwgADa4wCAAJ/ugIAAAYCAgAAHUoCAAATdgIAAVEoAgAAr23g= Date: Wed, 20 Aug 2014 22:21:47 +0000 Message-ID: <12842_1408573308_53F51F7C_12842_165_1_bugohe4hsye5r7doltiqqwq4.1408573212615@email.android.com> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> , <1C418D2E-A120-4A24-9134-97906937E170@nostrum.com> In-Reply-To: <1C418D2E-A120-4A24-9134-97906937E170@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FMyMUNuI9B9yB4G43-3C9bhbHQ4 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 22:21:52 -0000 Hi Ben, I'm not ignoring the requirements. I'm saying that most of them are fulfilled in my point of view. And we have= also an.agreement that the baseline solution for DOIC may not cover everyt= hing but may be enhanced if required. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Ben Campbell a =E9crit ---- I'm a little confused by this discussion. We have a published DIME consensu= s document of DIME (RFC 7068) that has requirements that matter here, but t= he discussion seems content to ignore them. In particular, the following quoted requirements bear on this discussion. > REQ 6: The solution designers SHOULD seek to minimize the amount of > new configuration required in order to work. For example, it > is better to allow peers to advertise or negotiate support > for the solution, rather than to require that this knowledge > be configured at each node. > [...] > REQ 16: The solution is likely to be deployed incrementally. The > solution MUST support a mixed environment where some, but not > all, nodes implement it. > > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. > More inline: On Aug 20, 2014, at 11:43 AM, Nirav Salot (nsalot) wrote: > Steve, > > You are proposing a change (minor or not) for a problem which does not ex= ist (in my view at least) since the use case is > - The operator has enabled overload feature in his network and has not up= graded one of the proxy > - The operator has "forgotten" that the proxy which is not upgraded is do= ing topology hiding Steve is proposing a change to allow incremental deployment without breakin= g things (Req 16, and first part of Req 17). In this case, the incremental = deployment is to allow at least some DOIC function, in spite of a legacy pr= oxy. I believe these requirements require us to at least attempt to solve t= he problem. If we can't come up with a solution, we should document why, an= d try to keep our non-compliance as narrow as possible. (This is significan= tly different from saying that the problem does not need to be solved.) > > Or between two operators, they have entered into the agreement to share t= he overload reports but have not bothered to upgrade all of their nodes and= not done any basic testing before activating the overload feature. > > So we are defining the solution for the above use cases. And the solution= you are suggesting it results in > - The client ignoring the overload report and thus the operator finds out= that "he has forgotten to upgrade one of the proxy (which is doing topolog= y hiding) with the overload feature". > > Additionally, the solution breaks topology hiding feature itself and your= justification is that "we haven't agreed requirement to not break this fea= ture!". This is the one problem I see with the current proposal. I'd like to see co= mments from some of the carriers about whether it's a show stopper. We shou= ld also wrack our brains for a solution that does not have this problem. (T= hanks to Dave for taking a shot at that--it would be good to see other thou= ghts there.) I note that topology-hiding for it's own sake. is not the only use case for= which proxies munge origin-host in answers. There are other cases (for exa= mple, having the proxy completely take over responsibility for request rout= ing), where this leakage is not a problem. You may recall all the early dis= cussions about server front ends (SFEs), where they _always_ did origin-hos= t munging, but only sometimes did full-blown topology hiding. This is not theoretical. Such proxies exist in real deployments today. > > I am sorry, but I don't see why we need any protocol based solution here. > It is simple matter operator knowing its network/deployment/nodes and exi= sting features and enabling new feature based on "this" knowledge. And doin= g some basic testing/dry run before going live. > 3GPP or IETF, if we start defining solution assuming that "but the operat= or may have forgotten to do this or that", we are adding solutions in our p= roduct which are simply overhead. You seem to be ignoring Req 6. Also, while the idea that you need to test e= verything out in advance may make sense from a 3GPP perspective, it doesn't= from an IETF perspective, where we have to worry about things like dynamic= discovery (which makes Req 5 also relevant.) If you use dynamic peer disco= very, you can't know in advance the features of every node you may talk to = (or across.) > > Finally, we should be looking at the justification to have some solution = and not add some change just because it is minor. Again, the quoted requirements are represent existing consensus. Certainly = we can change consensus--but doing so requires a consensus to do so. If on the other hand, people think these requirements do not apply to the p= roblem at hand, they can argue that. But if people have argued that so far,= I've missed it. ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Aug 20 15:29:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93721A8A50 for ; Wed, 20 Aug 2014 15:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bun5mVRyqbnE for ; Wed, 20 Aug 2014 15:28:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DF01A8A43 for ; Wed, 20 Aug 2014 15:28:54 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7KMSmYh082238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 17:28:49 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <12842_1408573308_53F51F7C_12842_165_1_bugohe4hsye5r7doltiqqwq4.1408573212615@email.android.com> Date: Wed, 20 Aug 2014 17:28:48 -0500 X-Mao-Original-Outgoing-Id: 430266528.027038-8bf55b0d72cfc3e0958748663fc5a98b Content-Transfer-Encoding: quoted-printable Message-Id: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> , <1C418D2E-A120-4A24-9134-97906937E170@nostrum.com> <12842_1408573308_53F51F7C_12! 842_165_1_bugohe4hsye5r7doltiqqwq4.1408573212615@email.android.com> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mG4kfFjSRoq0jY9qpPMpFs8r8Cg Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 22:28:56 -0000 On Aug 20, 2014, at 5:21 PM, = wrote: > Hi Ben, >=20 > I'm not ignoring the requirements. > I'm saying that most of them are fulfilled in my point of view. And we = have also an.agreement that the baseline solution for DOIC may not cover = everything but may be enhanced if required. IMO, Putting off a requirement for later work is fine, if we document = that we did so and have a reasonable path to doing it in the future. = But I'm not sure how this one can be fixed after the fact, unless we = build the needed flexibility into the initial mechanism. From nobody Thu Aug 21 02:11:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCCC1A00A8 for ; Thu, 21 Aug 2014 02:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVM0xeDXolP4 for ; Thu, 21 Aug 2014 02:11:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646971A0062 for ; Thu, 21 Aug 2014 02:11:23 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 59C732AC349; Thu, 21 Aug 2014 11:11:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3C992384061; Thu, 21 Aug 2014 11:11:21 +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.03.0195.001; Thu, 21 Aug 2014 11:11:21 +0200 From: To: Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPu7xAixeXE7DuBE6VeIfag6SAwpvYCiZwgADa4wCAAJ/ugIAAAYCAgAAHUoCAAATdgIAAVEoAgAAr23j//+BtAIAAzwfQ Date: Thu, 21 Aug 2014 09:11:20 +0000 Message-ID: <2691_1408612281_53F5B7B9_2691_52_6_6B7134B31289DC4FAF731D844122B36E6C18EE@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> , <1C418D2E-A120-4A24-9134-97906937E170@nostrum.com> <12842_1408573308_53F51F7C_12! 842_165_1_bugohe4hsye5r7doltiqqwq4.1408573212615@email.android.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: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.220919 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5oUeUiLtiVz7aX_F4llxzyvvAqQ Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 09:11:29 -0000 The flexibility is there if it is just about adding an AVP in the Grouped A= VP. As far as I understand, the question is more about the real need for such e= xtension today. -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: jeudi 21 ao=FBt 2014 00:29 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Nirav Salot (nsalot); Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is On Aug 20, 2014, at 5:21 PM, wrote: > Hi Ben, >=20 > I'm not ignoring the requirements. > I'm saying that most of them are fulfilled in my point of view. And we ha= ve also an.agreement that the baseline solution for DOIC may not cover ever= ything but may be enhanced if required. IMO, Putting off a requirement for later work is fine, if we document that = we did so and have a reasonable path to doing it in the future. But I'm no= t sure how this one can be fixed after the fact, unless we build the needed= flexibility into the initial mechanism. ___________________________________________________________________________= ______________________________________________ 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. From nobody Thu Aug 21 07:22:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990CC1A035D for ; Thu, 21 Aug 2014 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOV1hQYrp1Es for ; Thu, 21 Aug 2014 07:22:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128331A0334 for ; Thu, 21 Aug 2014 07:22:29 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7LEMHJB065314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Aug 2014 09:22:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <2691_1408612281_53F5B7B9_2691_52_6_6B7134B31289DC4FAF731D844122B36E6C18EE@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 21 Aug 2014 09:22:17 -0500 X-Mao-Original-Outgoing-Id: 430323737.406962-e19b8f9ca5429dc92ab43f674431f3d0 Content-Transfer-Encoding: quoted-printable Message-Id: <31AE1C80-F4F8-487C-BF6F-2F41FFD2D552@nostrum.com> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> , <1C418D2E-A120-4A24-9134-97906937E170@nostrum.com> <12842_1408573308_53F51F7C_12! ! 842_165_1_bugohe4hsye5r7doltiqqwq4.1408573212615@email.android.com> <2691_1408612281_53F5B7B9_2691_52_6_6B7134B31289DC4FAF731D844122B36E6C18EE@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5Vxc15mXff6Jz3cD1QrM-vLu4jE Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 14:22:30 -0000 On Aug 21, 2014, at 4:11 AM, lionel.morand@orange.com wrote: > The flexibility is there if it is just about adding an AVP in the = Grouped AVP. > As far as I understand, the question is more about the real need for = such extension today. >=20 The problem is, this only works if the reacting node knows that it needs = to pay attention to the new AVP. Would you advocate setting the M-bit? > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : jeudi 21 ao=FBt 2014 00:29 > =C0 : MORAND Lionel IMT/OLN > Cc : Nirav Salot (nsalot); Steve Donovan; dime@ietf.org > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives = analysis >=20 >=20 > On Aug 20, 2014, at 5:21 PM, = wrote: >=20 >> Hi Ben, >>=20 >> I'm not ignoring the requirements. >> I'm saying that most of them are fulfilled in my point of view. And = we have also an.agreement that the baseline solution for DOIC may not = cover everything but may be enhanced if required. >=20 > IMO, Putting off a requirement for later work is fine, if we document = that we did so and have a reasonable path to doing it in the future. = But I'm not sure how this one can be fixed after the fact, unless we = build the needed flexibility into the initial mechanism. >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Thu Aug 21 08:32:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9C51A040A for ; Thu, 21 Aug 2014 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opb0q4AQsF2U for ; Thu, 21 Aug 2014 08:32:36 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF891A03F6 for ; Thu, 21 Aug 2014 08:31:35 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52977 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XKUKo-0007dX-JL; Thu, 21 Aug 2014 08:31:34 -0700 Message-ID: <53F610D1.4070007@usdonovans.com> Date: Thu, 21 Aug 2014 10:31:29 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "lionel.morand@orange.com" , Ben Campbell References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kbicGSot6RQcQcLdvbEcRCYgOs0 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 15:32:40 -0000 Nirav, Thanks for the detailed response. Please see my responses inline. Steve On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote: > Steve, > > You are proposing a change (minor or not) for a problem which does not exist (in my view at least) since the use case is > - The operator has enabled overload feature in his network and has not upgraded one of the proxy > - The operator has "forgotten" that the proxy which is not upgraded is doing topology hiding SRD> It's not just about topology hiding. It's about anything that requires changing the origin-host. > > Or between two operators, they have entered into the agreement to share the overload reports but have not bothered to upgrade all of their nodes and not done any basic testing before activating the overload feature. SRD> I don't think we want to get into the situation where Operator A has to wait to turn on overload control because Operator B has not yet upgraded their network to support DOIC. > > So we are defining the solution for the above use cases. And the solution you are suggesting it results in > - The client ignoring the overload report and thus the operator finds out that "he has forgotten to upgrade one of the proxy (which is doing topology hiding) with the overload feature". SRD> I'm saying that in the real world strange things happen. Solution 1 mitigates the effect of mistakes being made. SRD> I'm not saying the client ignores the overload report. That is clearly one option. I have suggested the behavior be up to local policy. I see four options, others may see others: 1) Always ignore the overload report 2) Always honor the overload report 3) Conditionally honor the overload report -- Honor anything up to some percentage 4) Adjusted percentage - learn the number of servers that exist behind the OHMA and adjust the reduction percentage accordingly. > > Additionally, the solution breaks topology hiding feature itself and your justification is that "we haven't agreed requirement to not break this feature!". SRD> As pointed out by Dave, there are likely modifications to solution 1 that does not break topology hiding, if we think it is a requirement to avoid that breakage. SRD> Which is worse, an operator not being able to turn on DOIC because of other operators or breaking topology hiding? I don't know the answer but I do think it is a decision that should be made by the operator. > > I am sorry, but I don't see why we need any protocol based solution here. SRD> This is where the difference of opinion exists. You are of the opinion that operators never make mistakes and, as a result, we don't need a protocol based solution. I am of the opinion that in the real world strange things happen and a little bit of extra resiliency in the protocol is a good thing. > It is simple matter operator knowing its network/deployment/nodes and existing features and enabling new feature based on "this" knowledge. And doing some basic testing/dry run before going live. > 3GPP or IETF, if we start defining solution assuming that "but the operator may have forgotten to do this or that", we are adding solutions in our product which are simply overhead. > > Finally, we should be looking at the justification to have some solution and not add some change just because it is minor. SRD> No one is making that argument. I have articulated the justification. I also pointed out that the cost of the solution is very small. Cost benefit analysis is a valid aspect of any design process. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:56 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis > > Nirav, > > Can you please be more specific about which of the explanations you don't agree with? > > I agree we can't completely ignore the way that Diameter is being used. > > We should also be avoiding a solution that leaves open the possibility of significant under utilization of Diameter network resources. We have a stated requirement that the solution must not result in under utilization. > > I must admit I'm surprised at the response the proposal is getting. It is a very minor change that makes the protocol more resilient. > > Steve > > On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: >> Steve, >> >> I don't agree with your explanations. >> >> Additionally, we may not have explicit requirement to make DOIC work in the face of topology hiding but that does not mean that "DOIC can break any existing feature - be it topology hiding - and that's fine!". >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 20, 2014 9:24 PM >> To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> Nirav, >> >> Please see my comments inline. >> >> Steve >> >> On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >>> I agree with Lionel on multiple accounts. >>> I don't see any value in alternative 1. In fact, as I had already indicated, the alternative 1 breaks one or more of existing feature and hence it is not a solution by itself. >> SRD> The value is that, through a protocol solution, we can make it >> possible to prevent a complete shutdown of all traffic through a OHMA. >> It might be a small probability, but it is > 0, the impact is significant and the cost of the proposed protocol solution is extremely small. >> >> SRD> I'm assuming that the breakage you are talking about is that the >> proposal does allow for topology information to leak across operator boundaries. This is true, however, we do not, however, have a requirement to make DOIC work in the face of topology hiding. Are there other existing features that you are concerned about? >>> Additionally, like any other feature, the operator does not simply enable this feature in their network without considerable planning, lab and field testing. And this is true for between two operators as well - where the bigger issue is whether to expose the overload information between two PLMNs or not. >> SRD> We are designing DOIC for Diameter usage in general, not just >> 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at least for well disciplined operators that have extensive testing as you point out. I don't, however, think we can make that assumption across all uses of Diameter. That's one of the reasons why we have requirements stating that the solution should not rely on configuration. >>> So I don't see the need to have protocol based solution to help operator debug "what they have forgotten about their network". >> SRD> As has been pointed out multiple times, this is not just about >> SRD> the >> operator's own network. The negative impacts can result from another operator not upgrading their agents to support DOIC. >> >> SRD> I look at this as a low cost insurance policy. It doesn't hurt >> anything to add this small change and it helps prevent would could be a major outage. >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>> lionel.morand@orange.com >>> Sent: Tuesday, August 19, 2014 8:57 PM >>> To: Steve Donovan; Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >>> analysis >>> >>> Hi Steve, >>> >>> If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC. >>> If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network. >>> And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC. >>> >>> About alt 1: >>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>> The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi >>> 19 août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> More inline. >>> >>> Steve >>> >>> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> See below. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi >>>> 19 août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> Lionel, >>>> >>>> There are two primary reasons that I think option 1 is important: >>>> >>>> 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA). >>>> >>>> 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA. >>>> >>>> Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about. >>>> >>>> [LM] And I disagree. >>>> >>>> More inline. >>>> [LM] same >>>> >>>> Steve >>>> >>>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>>> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. >>>> SRD> I don't understand this argument. It is perfectly valid for a >>>> client or server to advertise support for an application and not also support DOIC. Why do you imply that it would be different for an agent? >>>> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network. >>> SRD2> Consider the following timeline: >>> >>> Date - Event: >>> >>> Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic. In 2011 this works perfectly well for all applications handled by the agent. >>> >>> Sometime in 2015 - The IETF publishes the DOIC specification. >>> >>> Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later? >>>>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. >>>> SRD> See above. >>>> [LM] still unclear >>> SRD2> Detection of the fact that an OHMA exists so that something >>> intelligent can be done before it results in a total shutdown of the Diameter network. >>>>> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action. >>>> SRD> The reasons so far for deferring functionality was because it >>>> SRD> would >>>> add risk to the schedule for finishing the core DOIC solution. That is not the case here. We have a very small change to the specification that addresses multiple requirements. >>>> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR? >>> SRD> Scroll down an look at the details behind alternative 1. >>>>> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : >>>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>>> alternatives analysis >>>>> >>>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>>> >>>>> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important. >>>>> >>>>> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work. >>>>> >>>>> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>>> >>>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >>>>> >>>>>> All, >>>>>> >>>>>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents. The operators can then take any administrative action necessary to fix the issue. It is also a more general solution that does not rely on one industries interop procedures. >>>>>> >>>>>> If we can get agreement on this then we can start making progress on the remainder of the document. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread: >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>>> >>>>>>>>> One example of the impact of the issue is defined in this message: >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>>> >>>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the OC-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP. When there is a difference, the reacting node should report on the condition (event/alarm). Local policy would determine if the reacting node honors the overload report or ignores the overload report. >>>>>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason. >>>>>>>> >>>>>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC. >>>>>>>>> >>>>>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent. >>>>>>>>> >>>>>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> Option 1 Pros: >>>>>>>>> ------------ >>>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction. >>>>>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent. >>>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy. >>>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required. >>>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network. >>>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network. >>>>>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause. >>>>>>>> >>>>>>>>> Option 1 Cons: >>>>>>>>> ------------- >>>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>>> overload control >>>>>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information. >>>>>>>> >>>>>>>>> Option 2 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>>> management of overload conditions >>>>>>>>> >>>>>>>>> Option 2 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires the operator to lose any functionality enabled by >>>>>>>>> the non-DOIC agent until all agents have been upgraded to >>>>>>>>> support DOIC >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off. >>>>>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>>> requirement about not interfering with existing network features. >>>>>>>> If we had that, Option 2 would not comply.) >>>>>>>> >>>>>>>>> Option 3 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out. >>>>>>>> For very limited definitions of "rolled out." >>>>>>>> >>>>>>>>> Option 3 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>>> reports are sent) >>>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>>> - Limits ability of operator to fully control overload >>>>>>>>> >>>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1. Partially misses 34. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> ___________________________________________________________________ >>>>> _ _ _ ___________________________________________________ >>>>> >>>>> 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. >>>>> >>>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> 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. >>>> >>>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> 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. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > From nobody Thu Aug 21 09:49:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99811A0453 for ; Thu, 21 Aug 2014 09:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.169 X-Spam-Level: X-Spam-Status: No, score=-17.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF8B-Ef_gUob for ; Thu, 21 Aug 2014 09:49:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4961A06A2 for ; Thu, 21 Aug 2014 09:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27482; q=dns/txt; s=iport; t=1408639760; x=1409849360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ddf+229vuaYlCDjontemLDCjo5iEzE+po7cIvBz/x3s=; b=Ib/S41uFWVWBSmmldm6GJKesjwEpAo7O9sRYkQ5tQpSMRYv5Mr/KZ/lD vHfzCMmU3lCEGOlgq4iY8Ze7UGZ69oW4uN9/WY07WYsQChrrsvJL31WnQ krPLeocKoWnc2+Tt4uL6Ioy/bHoDa4XOHDv69T2HPhIBfi6i2QGyErDcT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAMgi9lOtJV2d/2dsb2JhbABRCYMNU1cEzEMKh04BgQ8Wd4QDAQEBAwEBAQEXVAsMBAIBCA4DBAEBAQoLEgcnCxQJCAIEAQ0FCAESiB8IDcJzF4cOh1wHAwEFAgENETECBQYEgyWBHQWGEYRVhj+gLINebAGBBQEBHiKBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,909,1406592000"; d="scan'208";a="71240572" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 21 Aug 2014 16:49:18 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7LGnIJx019405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 16:49:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 11:49:18 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxfVqBhvX9KFZEqyeV+fWGbNs5vHXswAgAZgQoCACY6AgIAAPboAgACH4wCAAB9igIAAIXaAgAASEwCAAAuUgIAApK0QgAD1QoD//60HEIAAW8uA//+sc4CAAda4gP//vOhA Date: Thu, 21 Aug 2014 16:49:17 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> <53F610D1.4070007@usdonovans.com> In-Reply-To: <53F610D1.4070007@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.83] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uTmHGXBDNycZt6KCpjNi_KYsG2M Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 16:49:24 -0000 Steve, SRD> Which is worse, an operator not being able to turn on DOIC because=20 of other operators or breaking topology hiding? I don't know the answer=20 but I do think it is a decision that should be made by the operator. I am not sure why should operator A not turn on DOIC feature in its own net= work just because of operator B/C/D does not support it. This is handled in the same way as operator A and B support the feature but= have no agreement to share the overload report. And hence based on configu= ration host in operator A's network ensures that messages going to operator= B does not contain overload report. Regards, Nirav.=20 -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Thursday, August 21, 2014 9:01 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Nirav, Thanks for the detailed response. Please see my responses inline. Steve On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote: > Steve, > > You are proposing a change (minor or not) for a problem which does not ex= ist (in my view at least) since the use case is > - The operator has enabled overload feature in his network and has not up= graded one of the proxy > - The operator has "forgotten" that the proxy which is not upgraded is do= ing topology hiding SRD> It's not just about topology hiding. It's about anything that=20 requires changing the origin-host. > > Or between two operators, they have entered into the agreement to share t= he overload reports but have not bothered to upgrade all of their nodes and= not done any basic testing before activating the overload feature. SRD> I don't think we want to get into the situation where Operator A=20 has to wait to turn on overload control because Operator B has not yet=20 upgraded their network to support DOIC. > > So we are defining the solution for the above use cases. And the solution= you are suggesting it results in > - The client ignoring the overload report and thus the operator finds out= that "he has forgotten to upgrade one of the proxy (which is doing topolog= y hiding) with the overload feature". SRD> I'm saying that in the real world strange things happen. Solution 1=20 mitigates the effect of mistakes being made. SRD> I'm not saying the client ignores the overload report. That is=20 clearly one option. I have suggested the behavior be up to local=20 policy. I see four options, others may see others: 1) Always ignore the overload report 2) Always honor the overload report 3) Conditionally honor the overload report -- Honor anything up to some=20 percentage 4) Adjusted percentage - learn the number of servers that exist behind=20 the OHMA and adjust the reduction percentage accordingly. > > Additionally, the solution breaks topology hiding feature itself and your= justification is that "we haven't agreed requirement to not break this fea= ture!". SRD> As pointed out by Dave, there are likely modifications to solution=20 1 that does not break topology hiding, if we think it is a requirement=20 to avoid that breakage. SRD> Which is worse, an operator not being able to turn on DOIC because=20 of other operators or breaking topology hiding? I don't know the answer=20 but I do think it is a decision that should be made by the operator. > > I am sorry, but I don't see why we need any protocol based solution here. SRD> This is where the difference of opinion exists. You are of the=20 opinion that operators never make mistakes and, as a result, we don't=20 need a protocol based solution. I am of the opinion that in the real=20 world strange things happen and a little bit of extra resiliency in the=20 protocol is a good thing. > It is simple matter operator knowing its network/deployment/nodes and exi= sting features and enabling new feature based on "this" knowledge. And doin= g some basic testing/dry run before going live. > 3GPP or IETF, if we start defining solution assuming that "but the operat= or may have forgotten to do this or that", we are adding solutions in our p= roduct which are simply overhead. > > Finally, we should be looking at the justification to have some solution = and not add some change just because it is minor. SRD> No one is making that argument. I have articulated the=20 justification. I also pointed out that the cost of the solution is very=20 small. Cost benefit analysis is a valid aspect of any design process. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:56 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analy= sis > > Nirav, > > Can you please be more specific about which of the explanations you don't= agree with? > > I agree we can't completely ignore the way that Diameter is being used. > > We should also be avoiding a solution that leaves open the possibility of= significant under utilization of Diameter network resources. We have a st= ated requirement that the solution must not result in under utilization. > > I must admit I'm surprised at the response the proposal is getting. It is= a very minor change that makes the protocol more resilient. > > Steve > > On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: >> Steve, >> >> I don't agree with your explanations. >> >> Additionally, we may not have explicit requirement to make DOIC work in = the face of topology hiding but that does not mean that "DOIC can break any= existing feature - be it topology hiding - and that's fine!". >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 20, 2014 9:24 PM >> To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> Nirav, >> >> Please see my comments inline. >> >> Steve >> >> On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >>> I agree with Lionel on multiple accounts. >>> I don't see any value in alternative 1. In fact, as I had already indic= ated, the alternative 1 breaks one or more of existing feature and hence it= is not a solution by itself. >> SRD> The value is that, through a protocol solution, we can make it >> possible to prevent a complete shutdown of all traffic through a OHMA. >> It might be a small probability, but it is > 0, the impact is significan= t and the cost of the proposed protocol solution is extremely small. >> >> SRD> I'm assuming that the breakage you are talking about is that the >> proposal does allow for topology information to leak across operator bou= ndaries. This is true, however, we do not, however, have a requirement to = make DOIC work in the face of topology hiding. Are there other existing fe= atures that you are concerned about? >>> Additionally, like any other feature, the operator does not simply enab= le this feature in their network without considerable planning, lab and fie= ld testing. And this is true for between two operators as well - where the = bigger issue is whether to expose the overload information between two PLMN= s or not. >> SRD> We are designing DOIC for Diameter usage in general, not just >> 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at = least for well disciplined operators that have extensive testing as you poi= nt out. I don't, however, think we can make that assumption across all use= s of Diameter. That's one of the reasons why we have requirements stating = that the solution should not rely on configuration. >>> So I don't see the need to have protocol based solution to help operato= r debug "what they have forgotten about their network". >> SRD> As has been pointed out multiple times, this is not just about >> SRD> the >> operator's own network. The negative impacts can result from another op= erator not upgrading their agents to support DOIC. >> >> SRD> I look at this as a low cost insurance policy. It doesn't hurt >> anything to add this small change and it helps prevent would could be a = major outage. >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>> lionel.morand@orange.com >>> Sent: Tuesday, August 19, 2014 8:57 PM >>> To: Steve Donovan; Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >>> analysis >>> >>> Hi Steve, >>> >>> If you decide to deploy a proxy modifying the origin-host, it would be = for some specific purposes in a given context. If the context has changed, = you will have to reconsider the whole mechanism. And it is not only related= to DOIC. >>> If not done, this is what I'm calling a bad design: it is not only abou= t the implementation of the product itself, it is also about how this produ= ct is used in the operational network. >>> And I don't buy the argument that an operator might have forgotten that= a proxy modifying origin-host would have been deployed in the network befo= re the introduction of DOIC. >>> >>> About alt 1: >>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the O= C-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR r= eport when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When ther= e is a difference, the reacting node should report on the condition (event/= alarm). Local policy would determine if the reacting node honors the overl= oad report or ignores the overload report. >>> The following question still remain not answered: if the proxy replaces= the origin-host A by origin-host B, the Diameter nodes receiving the answe= rs will "see" B as sender of the answer and will use this id when sending n= ew requests with origin-host AVP. So can you remind me how exactly the reac= ting node will use the Diameter-id received in the OLR? >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>> 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> More inline. >>> >>> Steve >>> >>> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> See below. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>>> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> Lionel, >>>> >>>> There are two primary reasons that I think option 1 is important: >>>> >>>> 1) This scenario can result in significant under utilization of resour= ces, to the extreme of completely shutting down all traffic to the servers = behind the Origin-Host Munging Agent (OHMA). >>>> >>>> 2) It gives operates a way to detect the unplanned or forgotten instan= ce of the OHMA. >>>> >>>> Being able to prevent number 1 is enough reason for me to add the very= small amount of additional protocol machinery we are talking about. >>>> >>>> [LM] And I disagree. >>>> >>>> More inline. >>>> [LM] same >>>> >>>> Steve >>>> >>>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>>> Because a a gent modifying the Origin-host can only be a proxy and a = proxy is by definition compliant with the application supporting the new OL= R-related AVPs, everything else is out of scope of the standardization. >>>> SRD> I don't understand this argument. It is perfectly valid for a >>>> client or server to advertise support for an application and not also = support DOIC. Why do you imply that it would be different for an agent? >>>> [LM] A proxy that would modify the origin-host without taking into acc= ount the possible use of this origin-host at the application would be a bad= ly-designed proxy and should not be used in operational network. >>> SRD2> Consider the following timeline: >>> >>> Date - Event: >>> >>> Sometime in 2011 - Operator installs an agent to do topology hiding or = load balancing or some other function and the agent modifies the origin-hos= t AVP as part of its logic. In 2011 this works perfectly well for all appl= ications handled by the agent. >>> >>> Sometime in 2015 - The IETF publishes the DOIC specification. >>> >>> Are you asserting that the agent deployed in 2011 was badly designed be= cause it did not anticipate the DOIC solution published four years later? >>>>> Moreover, the real added-value of the addition of the diameter-id in = the OLR does not seem so clear. >>>> SRD> See above. >>>> [LM] still unclear >>> SRD2> Detection of the fact that an OHMA exists so that something >>> intelligent can be done before it results in a total shutdown of the Di= ameter network. >>>>> Finally, we have agreed that the basic mechanism proposed in the draf= t may not cover all the use cases (existing or future) and can be enhanced = if required, with or without the need for a IETF standard action. >>>> SRD> The reasons so far for deferring functionality was because it >>>> SRD> would >>>> add risk to the schedule for finishing the core DOIC solution. That i= s not the case here. We have a very small change to the specification that= addresses multiple requirements. >>>> [LM] is there any clear description of what will be the use of this in= fo by the reacting node? if the proxy replaces the origin-host A by origin-= host B, the Diameter nodes receiving the answers will "see" B as sender of = the answer and will use this id when sending new requests with origin-host = AVP. So can you remind me how exactly the reacting node will use the Diamet= er-id received in the OLR? >>> SRD> Scroll down an look at the details behind alternative 1. >>>>> For all these reasons, I would recommend not to add this Diameter-id = in the OLR and to assume that the Origin-host is not changed by agent in th= e path of the Diameter messages. Some extra text could also be added to cla= rify that proxies modifying the Origin-host would have to be upgraded to ma= nage consistently the OLR received in Diameter application messages. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>>> alternatives analysis >>>>> >>>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>>> >>>>> As Nirav pointed out, it has the potential to leak topology informati= on past a topology hiding proxy. (Unless we can come up with some attributi= on scheme that is not based on Diameter Identity or IP Address.) It may be = reasonable, to do this, but we would need some guidance to warn operators t= hat this may happen if they enable DOIC across a non-supporting, topology-h= iding proxy. It would become the operator's choice to decide which is more = important. >>>>> >>>>> The part I find unsatisfying, is what would happen if you had some pa= ths that supported DOIC (or did not do topology hiding), and some paths tha= t don't support DOIC also do topology hiding. This could become a pretty bi= g administrative hit, and violates the spirit and letter of our requirement= to avoid adding lots of configuration work. >>>>> >>>>> OTOH, if we had a mechanism where servers could detect the existence = of a non-DOIC, topology-hiding proxy, this could be at least partially auto= mated. I can think of multiple ways we could make it possible to tell if an= immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>>> >>>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: >>>>> >>>>>> All, >>>>>> >>>>>> My recommendation on this alternative 1 as it give operators the abi= lity to discover when there is an issue associated with "Origin-Host Mungin= g" agents. The operators can then take any administrative action necessary= to fix the issue. It is also a more general solution that does not rely o= n one industries interop procedures. >>>>>> >>>>>> If we can get agreement on this then we can start making progress on= the remainder of the document. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>>> Are there other thoughts on the pros and cons of the three proposal= s for resolution of issue #66? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> The issue with pre-DOIC agents changing origin-host was been disc= ussed in this thread: >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>>> >>>>>>>>> One example of the impact of the issue is defined in this message= : >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>>> >>>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the O= C-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR r= eport when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When ther= e is a difference, the reacting node should report on the condition (event/= alarm). Local policy would determine if the reacting node honors the overl= oad report or ignores the overload report. >>>>>>>> I think the last entry is worth further discussion, but it's proba= bly more important to make a high level decision first. But, at risk of get= ting ahead of myself: I have trouble imagining a situation where honoring t= he overload report will be harmful, since if there is an intervening OHMA, = the reacting node will not likely have any host-routed requests to the diam= eter-id from the OLR. OTOH, I have trouble imagining where honoring the rep= ort would be useful, for the same reason. >>>>>>>> >>>>>>>>> 2) Configuration in operator's networks to turn off origin-host m= unging behavior until the agent is upgraded to support DOIC. >>>>>>>>> >>>>>>>>> 3) Configuration of reporting nodes to not send overload reports,= either universally or for transactions that cross the origin-host munging = agent. >>>>>>>>> >>>>>>>>> I've compiled a starting point for a pros and cons analysis of th= e three approaches. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> Option 1 Pros: >>>>>>>>> ------------ >>>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC = origin-host-munging agent in the path of a transaction. >>>>>>>>> - Gives operators ability to manage the under utilization issue c= aused by the non-DOIC agent. >>>>>>>>> - Gives operators the ability to keep features requiring origin-h= ost munging turned on while DOIC is rolled out. >>>>>>>>> - Leaves the determination of which action to take in this scenar= io (honor or ignore overload reports) to operator policy. >>>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of c= onfiguration required. >>>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of = a single node overload on the traffic handled by other nodes in the network= . >>>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of = overload in a mixed DOIC environment on the overall capacity of the network= . >>>>>>>> Specifically, it complies with the MUST NOT make things worth clau= se, but does not comply with the SHOULD reduce overload clause. >>>>>>>> >>>>>>>>> Option 1 Cons: >>>>>>>>> ------------- >>>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>>> overload control >>>>>>>> One additional con is that, if the OHMA is there for the purposes = of true topology hiding, the identity in the OLR may leak topology informat= ion. >>>>>>>> >>>>>>>>> Option 2 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>>> management of overload conditions >>>>>>>>> >>>>>>>>> Option 2 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires the operator to lose any functionality enabled by >>>>>>>>> the non-DOIC agent until all agents have been upgraded to >>>>>>>>> support DOIC >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - There is not way to determine if all non-DOIC origin-host mungi= ng behavior has been turned off until an overload event happens, with poten= tial to have significant negative effects until the offending agent can be = found and the behavior turned off. >>>>>>>>> - Not always possible, as operator doesn't always have control ov= er non-DOIC agent as it might be in another operators network. Proposal to = address this through interop agreements but while this might work in 3GPP s= cenarios, not all Diameter deployments are 3GPP driven. >>>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>>> requirement about not interfering with existing network features. >>>>>>>> If we had that, Option 2 would not comply.) >>>>>>>> >>>>>>>>> Option 3 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Gives operators the ability to keep features requiring origin-h= ost munging turned on while DOIC is rolled out. >>>>>>>> For very limited definitions of "rolled out." >>>>>>>> >>>>>>>>> Option 3 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>>> reports are sent) >>>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>>> - Limits ability of operator to fully control overload >>>>>>>>> >>>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a s= imilar way as option 1. Partially misses 34. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> ___________________________________________________________________ >>>>> _ _ _ ___________________________________________________ >>>>> >>>>> 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 detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles 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 an= d 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. >>>>> >>>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> 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 detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles 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 b= e 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. >>>> >>>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc pas etre diffuses, exploites= ou copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange declin= e toute responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. >>> >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > From nobody Wed Aug 27 05:38:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD651A04A2 for ; Wed, 27 Aug 2014 05:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCZvQ3WnEI1b for ; Wed, 27 Aug 2014 05:38:32 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBEE1A03C4 for ; Wed, 27 Aug 2014 05:38:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64323 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMcUb-0001cb-Gq for dime@ietf.org; Wed, 27 Aug 2014 05:38:31 -0700 Message-ID: <53FDD141.7060105@usdonovans.com> Date: Wed, 27 Aug 2014 07:38:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3shi8Lj5d3r28cB8iyCYZXhKRTg Subject: [Dime] DOIC draft updated X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 27 Aug 2014 12:38:33 -0000 All, I have updated the DOIC draft to remove the concept of DOIC endpoint. This included removing the section that discussed endpoints and associations. The updated version of the -04 draft can be found here: https://github.com/jounikor/draft-docdt-dime-ovli This addresses issue #26, which I will close shortly. If issues are found with the modifications, please open a new issue in datatracker.. Regards, Steve From nobody Wed Aug 27 05:40:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5CE1A0404 for ; Wed, 27 Aug 2014 05:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFi8AOLTERbL for ; Wed, 27 Aug 2014 05:40:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9694A1A02D0 for ; Wed, 27 Aug 2014 05:40:34 -0700 (PDT) Received: from localhost ([::1]:52089 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XMcWR-0001EM-DQ; Wed, 27 Aug 2014 05:40:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 27 Aug 2014 12:40:19 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/26#comment:2 Message-ID: <081.41b641ed9fb478f723b0b1fa3ca17666@trac.tools.ietf.org> References: <066.2786f2def6b2de11bbdc948e9deec92b@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <066.2786f2def6b2de11bbdc948e9deec92b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7hlFJ9niSOUjHVaI5xPi1ZXdYdA Cc: dime@ietf.org Subject: Re: [Dime] [dime] #26 (draft-ietf-dime-ovli): Overload Control Endpoints under specified X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:40:36 -0000 #26: Overload Control Endpoints under specified Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Concept of DOIC endpoint and DOIC associations removed from the document per agreement reached in the Toronto IETF meeting. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: blocker | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Aug 27 14:23:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314B31A0745 for ; Wed, 27 Aug 2014 14:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YtVwrJwac8e for ; Wed, 27 Aug 2014 14:23:12 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2461A02FE for ; Wed, 27 Aug 2014 14:23:12 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60405 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMkgO-0007A0-52 for dime@ietf.org; Wed, 27 Aug 2014 14:23:11 -0700 Message-ID: <53FE4C3B.2040508@usdonovans.com> Date: Wed, 27 Aug 2014 16:23:07 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140827135330.8937.78208.idtracker@ietfa.amsl.com> In-Reply-To: <20140827135330.8937.78208.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140827135330.8937.78208.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090407050004040607020909" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TgdvL90XKQ0JHnfg-4in5t-VlYY Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-agent-overload-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 27 Aug 2014 21:23:14 -0000 This is a multi-part message in MIME format. --------------090407050004040607020909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit All, I have submitted a new version of the agent overload draft. The previous version had expired. The only change is the version number. Regards, Steve -------- Original Message -------- Subject: New Version Notification for draft-donovan-dime-agent-overload-02.txt Date: Wed, 27 Aug 2014 06:53:30 -0700 From: internet-drafts@ietf.org To: Steve Donovan , Steve Donovan A new version of I-D, draft-donovan-dime-agent-overload-02.txt has been successfully submitted by Steve Donovan and posted to the IETF repository. Name: draft-donovan-dime-agent-overload Revision: 02 Title: Diameter Agent Overload Document date: 2014-08-27 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-02.txt Status: https://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload/ Htmlized: http://tools.ietf.org/html/draft-donovan-dime-agent-overload-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-donovan-dime-agent-overload-02 Abstract: This specification documents an extension to the Diameter Overload Control (DOC) base solution. The extension addresses the handling of agent overload. Requirements 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. The IETF Secretariat --------------090407050004040607020909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit All,

I have submitted a new version of the agent overload draft.  The previous version had expired.

The only change is the version number.

Regards,

Steve


-------- Original Message --------
Subject: New Version Notification for draft-donovan-dime-agent-overload-02.txt
Date: Wed, 27 Aug 2014 06:53:30 -0700
From: internet-drafts@ietf.org
To: Steve Donovan <srdonovan@usdonovans.com>, Steve Donovan <srdonovan@usdonovans.com> 


A new version of I-D, draft-donovan-dime-agent-overload-02.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-agent-overload
Revision:	02
Title:		Diameter Agent Overload
Document date:	2014-08-27
Group:		Individual Submission
Pages:		13
URL:            http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-02.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-agent-overload-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-donovan-dime-agent-overload-02

Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  The extension addresses the handling of
   agent overload.

Requirements
                                                                                  


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.

The IETF Secretariat


--------------090407050004040607020909-- From nobody Wed Aug 27 14:23:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AFC1A0722 for ; Wed, 27 Aug 2014 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_u1B_zvXAHK for ; Wed, 27 Aug 2014 14:23:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E7E1A02E2 for ; Wed, 27 Aug 2014 14:23:54 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60406 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMkh4-0007lm-Bo for dime@ietf.org; Wed, 27 Aug 2014 14:23:53 -0700 Message-ID: <53FE4C65.2060700@usdonovans.com> Date: Wed, 27 Aug 2014 16:23:49 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140827135344.23242.12915.idtracker@ietfa.amsl.com> In-Reply-To: <20140827135344.23242.12915.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140827135344.23242.12915.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020000000504070203010109" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ny0g-1DQ94xOFou8HNsEuyeuvjg Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-doc-rate-control-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 27 Aug 2014 21:23:55 -0000 This is a multi-part message in MIME format. --------------020000000504070203010109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit All, I have submitted a new version of the DOIC rate abatement algorithm draft. The previous version had expired. The only change is the version number. Regards, Steve -------- Original Message -------- Subject: New Version Notification for draft-donovan-dime-doc-rate-control-01.txt Date: Wed, 27 Aug 2014 06:53:44 -0700 From: internet-drafts@ietf.org To: Steve Donovan , Steve Donovan , Eric Noel A new version of I-D, draft-donovan-dime-doc-rate-control-01.txt has been successfully submitted by Steve Donovan and posted to the IETF repository. Name: draft-donovan-dime-doc-rate-control Revision: 01 Title: Diameter Overload Rate Control Document date: 2014-08-27 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-donovan-dime-doc-rate-control-01.txt Status: https://datatracker.ietf.org/doc/draft-donovan-dime-doc-rate-control/ Htmlized: http://tools.ietf.org/html/draft-donovan-dime-doc-rate-control-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-donovan-dime-doc-rate-control-01 Abstract: This specification documents an extension to the Diameter Overload Control (DOC) base solution. This extension adds a new overload control algorithm. This algorithm allows for a server to specify a maximum rate at which Diameter requests are sent to the server. Requirements 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. The IETF Secretariat --------------020000000504070203010109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit All,

I have submitted a new version of the DOIC rate abatement algorithm draft.  The previous version had expired.

The only change is the version number.

Regards,

Steve



-------- Original Message --------
Subject: New Version Notification for draft-donovan-dime-doc-rate-control-01.txt
Date: Wed, 27 Aug 2014 06:53:44 -0700
From: internet-drafts@ietf.org
To: Steve Donovan <srdonovan@usdonovans.com>, Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <unknown-email-Eric-Noel@ietfa.amsl.com> 


A new version of I-D, draft-donovan-dime-doc-rate-control-01.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-doc-rate-control
Revision:	01
Title:		Diameter Overload Rate Control
Document date:	2014-08-27
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-donovan-dime-doc-rate-control-01.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-doc-rate-control/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-doc-rate-control-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-donovan-dime-doc-rate-control-01

Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  This extension adds a new overload
   control algorithm.  This algorithm allows for a server to specify a
   maximum rate at which Diameter requests are sent to the server.

Requirements
                                                                                  


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.

The IETF Secretariat


--------------020000000504070203010109-- From nobody Thu Aug 28 03:26:39 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4731A6F49 for ; Thu, 28 Aug 2014 03:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igWxfHABo_O6 for ; Thu, 28 Aug 2014 03:26:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87EB1A6F3A for ; Thu, 28 Aug 2014 03:26:33 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A8BF7C9BB4564; Thu, 28 Aug 2014 10:26:29 +0000 (GMT) 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 s7SAPZ3e028654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 12:26:28 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 28 Aug 2014 12:25:32 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "Nirav Salot (nsalot)" , Steve Donovan , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxfWEHmN9pZYckS/sFZJieII0JvG6XMAgAZgQ4CACY6AgIAAPbkAgACH5ACAAB9hgIAAIXaAgAASEwCAAAuVgIAA+gAAgACf7oCAAAGAgIAAB1KAgAAE3ICAAX5PgIAAFb2AgAq2D2A= Date: Thu, 28 Aug 2014 10:25:31 +0000 Message-ID: References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> <53F610D1.4070007@usdonovans.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.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zl-9vtWtmphItVCJ1FDeKm5cCx4 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Aug 2014 10:26:38 -0000 Dear all A long email thread on this topology hiding topic. I Would like to come ba= ck on the use cases. In the thread, two use cases were mentioned, are there others? - the SFE case, where a DA in front of a set of servers presents this set o= f servers as one Diameter node with a unique Diameter Host identity. The re= acting nodes only know this Diameter Host identity for their host requests.= Regarding DOIC, as the SFE objective is to present the group of servers as= one Diameter node it should apply to DOIC, meaning the DA aggregates the d= ifferent OLRs received from servers to build the OLR associated to the uniq= ue Diameter Host identity. Otherwise this Diameter node will send inconsi= stent OLRs, and then we try to find a solution requesting the reacting node= s, that may be in external networks to solve this DOIC issue internal to t= he servers and their SFE. Lionel did such a remark in his 19/08 mail " a= agent modifying the Origin-host can only be a proxy and a proxy is by defi= nition compliant with the application supporting the new OLR-related AVPs" = on which I agree. Furthermore the Steve's proposed solution would introduce a non consistent = behavior from the reacting node regarding traffic reduction. =20 - the external network case where the DA of the servers network interfacin= g external networks is doing topology hiding to present the servers as a u= nique Diameter node to external networks . I have the same remark as for SF= E, where the proposed solution will request the external network to solve t= he issue of the non DOIC DEA. There is also the case where the DEA modifies the Origin-Host but on a 1 t= o 1 basis, so allocating a different Origin-host identity for each server. = In this case, the DOIC works well without changes. The proposed solution w= ill, I think, here create mismatches, which do not exist.=20 I share the comments from several of us, to not consider this case as an ac= tual one to solve. If a DA presents a set of servers as a unique Diameter H= ost, either this overall entity (servers+DA) supports DOIC and behaves as a= reporting node towards reacting nodes or it does not. If it does not, no = OC-Supported-feature AVP should be sent by this entity in answers to reacti= ng nodes, that I think can be achieved.=20 Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) Envoy=E9=A0: jeudi 21 ao=FBt 2014 18:49 =C0=A0: Steve Donovan; lionel.morand@orange.com; Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is Steve, SRD> Which is worse, an operator not being able to turn on DOIC because of other operators or breaking topology hiding? I don't know the answer bu= t I do think it is a decision that should be made by the operator. I am not sure why should operator A not turn on DOIC feature in its own net= work just because of operator B/C/D does not support it. This is handled in the same way as operator A and B support the feature but= have no agreement to share the overload report. And hence based on configu= ration host in operator A's network ensures that messages going to operator= B does not contain overload report. Regards, Nirav.=20 -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Thursday, August 21, 2014 9:01 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Nirav, Thanks for the detailed response. Please see my responses inline. Steve On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote: > Steve, > > You are proposing a change (minor or not) for a problem which does not=20 > exist (in my view at least) since the use case is > - The operator has enabled overload feature in his network and has not=20 > upgraded one of the proxy > - The operator has "forgotten" that the proxy which is not upgraded is=20 > doing topology hiding SRD> It's not just about topology hiding. It's about anything that requires changing the origin-host. > > Or between two operators, they have entered into the agreement to share t= he overload reports but have not bothered to upgrade all of their nodes and= not done any basic testing before activating the overload feature. SRD> I don't think we want to get into the situation where Operator A=20 has to wait to turn on overload control because Operator B has not yet=20 upgraded their network to support DOIC. > > So we are defining the solution for the above use cases. And the solution= you are suggesting it results in > - The client ignoring the overload report and thus the operator finds out= that "he has forgotten to upgrade one of the proxy (which is doing topolog= y hiding) with the overload feature". SRD> I'm saying that in the real world strange things happen. Solution 1=20 mitigates the effect of mistakes being made. SRD> I'm not saying the client ignores the overload report. That is=20 clearly one option. I have suggested the behavior be up to local=20 policy. I see four options, others may see others: 1) Always ignore the overload report 2) Always honor the overload report 3) Conditionally honor the overload report -- Honor anything up to some=20 percentage 4) Adjusted percentage - learn the number of servers that exist behind=20 the OHMA and adjust the reduction percentage accordingly. > > Additionally, the solution breaks topology hiding feature itself and your= justification is that "we haven't agreed requirement to not break this fea= ture!". SRD> As pointed out by Dave, there are likely modifications to solution=20 1 that does not break topology hiding, if we think it is a requirement=20 to avoid that breakage. SRD> Which is worse, an operator not being able to turn on DOIC because=20 of other operators or breaking topology hiding? I don't know the answer=20 but I do think it is a decision that should be made by the operator. > > I am sorry, but I don't see why we need any protocol based solution here. SRD> This is where the difference of opinion exists. You are of the=20 opinion that operators never make mistakes and, as a result, we don't=20 need a protocol based solution. I am of the opinion that in the real=20 world strange things happen and a little bit of extra resiliency in the=20 protocol is a good thing. > It is simple matter operator knowing its network/deployment/nodes and exi= sting features and enabling new feature based on "this" knowledge. And doin= g some basic testing/dry run before going live. > 3GPP or IETF, if we start defining solution assuming that "but the operat= or may have forgotten to do this or that", we are adding solutions in our p= roduct which are simply overhead. > > Finally, we should be looking at the justification to have some solution = and not add some change just because it is minor. SRD> No one is making that argument. I have articulated the=20 justification. I also pointed out that the cost of the solution is very=20 small. Cost benefit analysis is a valid aspect of any design process. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:56 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analy= sis > > Nirav, > > Can you please be more specific about which of the explanations you don't= agree with? > > I agree we can't completely ignore the way that Diameter is being used. > > We should also be avoiding a solution that leaves open the possibility of= significant under utilization of Diameter network resources. We have a st= ated requirement that the solution must not result in under utilization. > > I must admit I'm surprised at the response the proposal is getting. It is= a very minor change that makes the protocol more resilient. > > Steve > > On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: >> Steve, >> >> I don't agree with your explanations. >> >> Additionally, we may not have explicit requirement to make DOIC work in = the face of topology hiding but that does not mean that "DOIC can break any= existing feature - be it topology hiding - and that's fine!". >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 20, 2014 9:24 PM >> To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> Nirav, >> >> Please see my comments inline. >> >> Steve >> >> On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >>> I agree with Lionel on multiple accounts. >>> I don't see any value in alternative 1. In fact, as I had already indic= ated, the alternative 1 breaks one or more of existing feature and hence it= is not a solution by itself. >> SRD> The value is that, through a protocol solution, we can make it >> possible to prevent a complete shutdown of all traffic through a OHMA. >> It might be a small probability, but it is > 0, the impact is significan= t and the cost of the proposed protocol solution is extremely small. >> >> SRD> I'm assuming that the breakage you are talking about is that the >> proposal does allow for topology information to leak across operator bou= ndaries. This is true, however, we do not, however, have a requirement to = make DOIC work in the face of topology hiding. Are there other existing fe= atures that you are concerned about? >>> Additionally, like any other feature, the operator does not simply enab= le this feature in their network without considerable planning, lab and fie= ld testing. And this is true for between two operators as well - where the = bigger issue is whether to expose the overload information between two PLMN= s or not. >> SRD> We are designing DOIC for Diameter usage in general, not just >> 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at = least for well disciplined operators that have extensive testing as you poi= nt out. I don't, however, think we can make that assumption across all use= s of Diameter. That's one of the reasons why we have requirements stating = that the solution should not rely on configuration. >>> So I don't see the need to have protocol based solution to help operato= r debug "what they have forgotten about their network". >> SRD> As has been pointed out multiple times, this is not just about >> SRD> the >> operator's own network. The negative impacts can result from another op= erator not upgrading their agents to support DOIC. >> >> SRD> I look at this as a low cost insurance policy. It doesn't hurt >> anything to add this small change and it helps prevent would could be a = major outage. >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>> lionel.morand@orange.com >>> Sent: Tuesday, August 19, 2014 8:57 PM >>> To: Steve Donovan; Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >>> analysis >>> >>> Hi Steve, >>> >>> If you decide to deploy a proxy modifying the origin-host, it would be = for some specific purposes in a given context. If the context has changed, = you will have to reconsider the whole mechanism. And it is not only related= to DOIC. >>> If not done, this is what I'm calling a bad design: it is not only abou= t the implementation of the product itself, it is also about how this produ= ct is used in the operational network. >>> And I don't buy the argument that an operator might have forgotten that= a proxy modifying origin-host would have been deployed in the network befo= re the introduction of DOIC. >>> >>> About alt 1: >>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the O= C-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR r= eport when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When ther= e is a difference, the reacting node should report on the condition (event/= alarm). Local policy would determine if the reacting node honors the overl= oad report or ignores the overload report. >>> The following question still remain not answered: if the proxy replaces= the origin-host A by origin-host B, the Diameter nodes receiving the answe= rs will "see" B as sender of the answer and will use this id when sending n= ew requests with origin-host AVP. So can you remind me how exactly the reac= ting node will use the Diameter-id received in the OLR? >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>> 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> More inline. >>> >>> Steve >>> >>> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> See below. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>>> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> Lionel, >>>> >>>> There are two primary reasons that I think option 1 is important: >>>> >>>> 1) This scenario can result in significant under utilization of resour= ces, to the extreme of completely shutting down all traffic to the servers = behind the Origin-Host Munging Agent (OHMA). >>>> >>>> 2) It gives operates a way to detect the unplanned or forgotten instan= ce of the OHMA. >>>> >>>> Being able to prevent number 1 is enough reason for me to add the very= small amount of additional protocol machinery we are talking about. >>>> >>>> [LM] And I disagree. >>>> >>>> More inline. >>>> [LM] same >>>> >>>> Steve >>>> >>>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>>> Because a a gent modifying the Origin-host can only be a proxy and a = proxy is by definition compliant with the application supporting the new OL= R-related AVPs, everything else is out of scope of the standardization. >>>> SRD> I don't understand this argument. It is perfectly valid for a >>>> client or server to advertise support for an application and not also = support DOIC. Why do you imply that it would be different for an agent? >>>> [LM] A proxy that would modify the origin-host without taking into acc= ount the possible use of this origin-host at the application would be a bad= ly-designed proxy and should not be used in operational network. >>> SRD2> Consider the following timeline: >>> >>> Date - Event: >>> >>> Sometime in 2011 - Operator installs an agent to do topology hiding or = load balancing or some other function and the agent modifies the origin-hos= t AVP as part of its logic. In 2011 this works perfectly well for all appl= ications handled by the agent. >>> >>> Sometime in 2015 - The IETF publishes the DOIC specification. >>> >>> Are you asserting that the agent deployed in 2011 was badly designed be= cause it did not anticipate the DOIC solution published four years later? >>>>> Moreover, the real added-value of the addition of the diameter-id in = the OLR does not seem so clear. >>>> SRD> See above. >>>> [LM] still unclear >>> SRD2> Detection of the fact that an OHMA exists so that something >>> intelligent can be done before it results in a total shutdown of the Di= ameter network. >>>>> Finally, we have agreed that the basic mechanism proposed in the draf= t may not cover all the use cases (existing or future) and can be enhanced = if required, with or without the need for a IETF standard action. >>>> SRD> The reasons so far for deferring functionality was because it >>>> SRD> would >>>> add risk to the schedule for finishing the core DOIC solution. That i= s not the case here. We have a very small change to the specification that= addresses multiple requirements. >>>> [LM] is there any clear description of what will be the use of this in= fo by the reacting node? if the proxy replaces the origin-host A by origin-= host B, the Diameter nodes receiving the answers will "see" B as sender of = the answer and will use this id when sending new requests with origin-host = AVP. So can you remind me how exactly the reacting node will use the Diamet= er-id received in the OLR? >>> SRD> Scroll down an look at the details behind alternative 1. >>>>> For all these reasons, I would recommend not to add this Diameter-id = in the OLR and to assume that the Origin-host is not changed by agent in th= e path of the Diameter messages. Some extra text could also be added to cla= rify that proxies modifying the Origin-host would have to be upgraded to ma= nage consistently the OLR received in Diameter application messages. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>>> alternatives analysis >>>>> >>>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>>> >>>>> As Nirav pointed out, it has the potential to leak topology informati= on past a topology hiding proxy. (Unless we can come up with some attributi= on scheme that is not based on Diameter Identity or IP Address.) It may be = reasonable, to do this, but we would need some guidance to warn operators t= hat this may happen if they enable DOIC across a non-supporting, topology-h= iding proxy. It would become the operator's choice to decide which is more = important. >>>>> >>>>> The part I find unsatisfying, is what would happen if you had some pa= ths that supported DOIC (or did not do topology hiding), and some paths tha= t don't support DOIC also do topology hiding. This could become a pretty bi= g administrative hit, and violates the spirit and letter of our requirement= to avoid adding lots of configuration work. >>>>> >>>>> OTOH, if we had a mechanism where servers could detect the existence = of a non-DOIC, topology-hiding proxy, this could be at least partially auto= mated. I can think of multiple ways we could make it possible to tell if an= immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>>> >>>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: >>>>> >>>>>> All, >>>>>> >>>>>> My recommendation on this alternative 1 as it give operators the abi= lity to discover when there is an issue associated with "Origin-Host Mungin= g" agents. The operators can then take any administrative action necessary= to fix the issue. It is also a more general solution that does not rely o= n one industries interop procedures. >>>>>> >>>>>> If we can get agreement on this then we can start making progress on= the remainder of the document. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>>> Are there other thoughts on the pros and cons of the three proposal= s for resolution of issue #66? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> The issue with pre-DOIC agents changing origin-host was been disc= ussed in this thread: >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>>> >>>>>>>>> One example of the impact of the issue is defined in this message= : >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>>> >>>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the O= C-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR r= eport when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When ther= e is a difference, the reacting node should report on the condition (event/= alarm). Local policy would determine if the reacting node honors the overl= oad report or ignores the overload report. >>>>>>>> I think the last entry is worth further discussion, but it's proba= bly more important to make a high level decision first. But, at risk of get= ting ahead of myself: I have trouble imagining a situation where honoring t= he overload report will be harmful, since if there is an intervening OHMA, = the reacting node will not likely have any host-routed requests to the diam= eter-id from the OLR. OTOH, I have trouble imagining where honoring the rep= ort would be useful, for the same reason. >>>>>>>> >>>>>>>>> 2) Configuration in operator's networks to turn off origin-host m= unging behavior until the agent is upgraded to support DOIC. >>>>>>>>> >>>>>>>>> 3) Configuration of reporting nodes to not send overload reports,= either universally or for transactions that cross the origin-host munging = agent. >>>>>>>>> >>>>>>>>> I've compiled a starting point for a pros and cons analysis of th= e three approaches. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> Option 1 Pros: >>>>>>>>> ------------ >>>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC = origin-host-munging agent in the path of a transaction. >>>>>>>>> - Gives operators ability to manage the under utilization issue c= aused by the non-DOIC agent. >>>>>>>>> - Gives operators the ability to keep features requiring origin-h= ost munging turned on while DOIC is rolled out. >>>>>>>>> - Leaves the determination of which action to take in this scenar= io (honor or ignore overload reports) to operator policy. >>>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of c= onfiguration required. >>>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of = a single node overload on the traffic handled by other nodes in the network= . >>>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of = overload in a mixed DOIC environment on the overall capacity of the network= . >>>>>>>> Specifically, it complies with the MUST NOT make things worth clau= se, but does not comply with the SHOULD reduce overload clause. >>>>>>>> >>>>>>>>> Option 1 Cons: >>>>>>>>> ------------- >>>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>>> overload control >>>>>>>> One additional con is that, if the OHMA is there for the purposes = of true topology hiding, the identity in the OLR may leak topology informat= ion. >>>>>>>> >>>>>>>>> Option 2 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>>> management of overload conditions >>>>>>>>> >>>>>>>>> Option 2 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires the operator to lose any functionality enabled by >>>>>>>>> the non-DOIC agent until all agents have been upgraded to >>>>>>>>> support DOIC >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - There is not way to determine if all non-DOIC origin-host mungi= ng behavior has been turned off until an overload event happens, with poten= tial to have significant negative effects until the offending agent can be = found and the behavior turned off. >>>>>>>>> - Not always possible, as operator doesn't always have control ov= er non-DOIC agent as it might be in another operators network. Proposal to = address this through interop agreements but while this might work in 3GPP s= cenarios, not all Diameter deployments are 3GPP driven. >>>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>>> requirement about not interfering with existing network features. >>>>>>>> If we had that, Option 2 would not comply.) >>>>>>>> >>>>>>>>> Option 3 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Gives operators the ability to keep features requiring origin-h= ost munging turned on while DOIC is rolled out. >>>>>>>> For very limited definitions of "rolled out." >>>>>>>> >>>>>>>>> Option 3 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>>> reports are sent) >>>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>>> - Limits ability of operator to fully control overload >>>>>>>>> >>>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a s= imilar way as option 1. Partially misses 34. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> ___________________________________________________________________ >>>>> _ _ _ ___________________________________________________ >>>>> >>>>> 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 detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles 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 an= d 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. >>>>> >>>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> 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 detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles 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 b= e 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. >>>> >>>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc pas etre diffuses, exploites= ou copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange declin= e toute responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. >>> >>> 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Aug 28 08:27:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7021A86F1 for ; Thu, 28 Aug 2014 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY7MULXg3WE7 for ; Thu, 28 Aug 2014 08:26:58 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E371A070C for ; Thu, 28 Aug 2014 08:26:18 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65053 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XN1aZ-0004oI-UN for dime@ietf.org; Thu, 28 Aug 2014 08:26:17 -0700 Message-ID: <53FF4A17.9050707@usdonovans.com> Date: Thu, 28 Aug 2014 10:26:15 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZsJ5Mpccmd8TLYIuiqYEl6OEG0M Subject: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Aug 2014 15:27:03 -0000 All, One of the open issues is the DOIC behavior when a DOIC node rejects a request as a result of an overload condition. Today, the logical error response would be the DIAMETER_TOO_BUSY response. The issue with this behavior is that it can result in the client retrying the request to an alternative peer. The desired behavior for a request rejected because of overload throttling is the same as if the client, acting as a reacting node, throttled the request. As a result, the transaction should not be retried. The proposal is to define a new protocol error response code called DIAMETER_THROTTLED with the defined behavior that the request SHOULD be treated as a final response and SHOULD NOT be retried. This error response could be generated by agents acting as reacting nodes or by any reporting node. A server, for instance, that is in a severe overload condition might chose to reject some transactions with the DIAMETER_THROTTLED response if the current requested reduction included in the overload report is not sufficient. One issue with this proposal is backwards compatibility with Diameter nodes that do not support DOIC and, as such, would not understand the DIAMETER_THROTTLED response. The proposal to address this is to make the generation of the DIAMETER_THROTTLED error response conditional. This is an attempt at wording this conditional behavior: A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transactions that are throttled and the DOIC node knows that there is a DOIC reacting node able to process the error response. The DOIC node generating the DIAMETER_THROTTLED error response determines that there there is a DOIC reacting node by the presence or absence of an OC-Supported-Features AVP in the request message for the transaction. If there is no OC-Supported-Features AVP in the request message for a transaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_BUSY response message. Assuming we get agreement on the proposal then I'll come back with detailed wording proposals for the DOIC specification. Regards, Steve From nobody Thu Aug 28 08:34:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B603C1A6F83 for ; Thu, 28 Aug 2014 08:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSPSkvmyq2La for ; Thu, 28 Aug 2014 08:34:25 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3811A0700 for ; Thu, 28 Aug 2014 08:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2837; q=dns/txt; s=iport; t=1409240065; x=1410449665; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9aSM6hummQz3h65G7wBXNX+THMGJoUjhK0joDVYB9+M=; b=RbscloLNTenblkP4WfSyxCyNQQsAzfrbWmd17NYw5FCwDtqRqqyvJutF UZd3S6omjhyxsg1ht+vk1p+b/PxfroeK4y2AkbXdnQA1dKR+FQdfYu/Wq fQT4JYN2BT9rqeGzbnca710bATqo0wNsVlPM8ShmGgdsrZNkTnydpLznv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHpL/1OtJV2Z/2dsb2JhbABbgw1TVwTMHgqHTwGBGhZ3hAMBAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiIOg2/TxMEjxs4BoMpgR0FkS+XQ4kFg15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208";a="73103750" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 28 Aug 2014 15:34:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7SFYOLU013799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:34:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:34:24 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposal for new error response for DOIC Thread-Index: AQHPwtSM6w23XF/IiEK7aWfc1k6gqpvmJHOg Date: Thu, 28 Aug 2014 15:34:23 +0000 Message-ID: References: <53FF4A17.9050707@usdonovans.com> In-Reply-To: <53FF4A17.9050707@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/V-63ae7L6ZsxLVfxbGiSyyOBc0E Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Aug 2014 15:34:26 -0000 Steve, I support the principle of the proposal - DOIC node should use the newly de= fined error code towards the DOIC supporting client. Should we explicitly specify that the request may be rejected even if the o= verload report was provided by the DOIC node? Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, August 28, 2014 8:56 PM To: dime@ietf.org Subject: [Dime] Proposal for new error response for DOIC All, One of the open issues is the DOIC behavior when a DOIC node rejects a requ= est as a result of an overload condition. Today, the logical error response would be the DIAMETER_TOO_BUSY response. = The issue with this behavior is that it can result in the client retrying = the request to an alternative peer. The desired behavior for a request rejected because of overload throttling = is the same as if the client, acting as a reacting node, throttled the requ= est. As a result, the transaction should not be retried. The proposal is to define a new protocol error response code called DIAMETE= R_THROTTLED with the defined behavior that the request SHOULD be treated as= a final response and SHOULD NOT be retried. This error response could be generated by agents acting as reacting nodes o= r by any reporting node. A server, for instance, that is in a severe overl= oad condition might chose to reject some transactions with the DIAMETER_THR= OTTLED response if the current requested reduction included in the overload= report is not sufficient. One issue with this proposal is backwards compatibility with Diameter nodes= that do not support DOIC and, as such, would not understand the DIAMETER_T= HROTTLED response. The proposal to address this is to make the generation = of the DIAMETER_THROTTLED error response conditional. =20 This is an attempt at wording this conditional behavior: A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transactio= ns that are throttled and the DOIC node knows that there is a DOIC reacting= node able to process the error response. The DOIC node generating the DIA= METER_THROTTLED error response determines that there there is a DOIC reacti= ng node by the presence or absence of an OC-Supported-Features AVP in the r= equest message for the transaction. If there is no OC-Supported-Features AVP in the request message for a trans= action that is throttled then the DOIC node SHOULD send the DIAMETER_TO_BUS= Y response message. Assuming we get agreement on the proposal then I'll come back with detailed= wording proposals for the DOIC specification. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Aug 28 12:57:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5EB1A8978 for ; Thu, 28 Aug 2014 12:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwpNxnt6hMjH for ; Thu, 28 Aug 2014 12:57:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812E51A897F for ; Thu, 28 Aug 2014 12:57:12 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7SJvAhG066325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 14:57:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53FF4A17.9050707@usdonovans.com> Date: Thu, 28 Aug 2014 14:57:09 -0500 X-Mao-Original-Outgoing-Id: 430948629.419504-aeb28fba749e14c74617c4ab4ae361f3 Content-Transfer-Encoding: quoted-printable Message-Id: <95D175DE-C80C-4690-95D8-14ABC6393A38@nostrum.com> References: <53FF4A17.9050707@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vbQoPBYXYT3K2fBKsOI4gUE8rh4 Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Aug 2014 19:57:14 -0000 I agree with doing this.=20 But I'm also concerned that the backwards compatibility issue you = mention means that this doesn't help in what is potentially the biggest = use case for throttling at an agent. that is, an agent throttling on = behalf of a non-supporting client. One approach would be to define DIAMETER_THROTTLED in a separate update = to RFC 6733, in hopes that people who aren't ready to fully support DOIC = might at least support the new error. (Yeah, I know that's a long shot.) = Another might be to write some additional (BCP?) guidance on how clients = should handle TOO_BUSY.=20 On Aug 28, 2014, at 10:26 AM, Steve Donovan = wrote: > All, >=20 > One of the open issues is the DOIC behavior when a DOIC node rejects a = request as a result of an overload condition. >=20 > Today, the logical error response would be the DIAMETER_TOO_BUSY = response. The issue with this behavior is that it can result in the = client retrying the request to an alternative peer. >=20 > The desired behavior for a request rejected because of overload = throttling is the same as if the client, acting as a reacting node, = throttled the request. As a result, the transaction should not be = retried. >=20 > The proposal is to define a new protocol error response code called = DIAMETER_THROTTLED with the defined behavior that the request SHOULD be = treated as a final response and SHOULD NOT be retried. >=20 > This error response could be generated by agents acting as reacting = nodes or by any reporting node. A server, for instance, that is in a = severe overload condition might chose to reject some transactions with = the DIAMETER_THROTTLED response if the current requested reduction = included in the overload report is not sufficient. >=20 > One issue with this proposal is backwards compatibility with Diameter = nodes that do not support DOIC and, as such, would not understand the = DIAMETER_THROTTLED response. The proposal to address this is to make = the generation of the DIAMETER_THROTTLED error response conditional. = This is an attempt at wording this conditional behavior: >=20 > A DOIC node SHOULD use the DIAMETER_THROTTLED error response for = transactions that are throttled and the DOIC node knows that there is a = DOIC reacting node able to process the error response. The DOIC node = generating the DIAMETER_THROTTLED error response determines that there = there is a DOIC reacting node by the presence or absence of an = OC-Supported-Features AVP in the request message for the transaction. >=20 > If there is no OC-Supported-Features AVP in the request message for a = transaction that is throttled then the DOIC node SHOULD send the = DIAMETER_TO_BUSY response message. >=20 > Assuming we get agreement on the proposal then I'll come back with = detailed wording proposals for the DOIC specification. >=20 > Regards, >=20 > Steve >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Aug 29 00:58:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64661A068E for ; Fri, 29 Aug 2014 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybfHnYtYeDI9 for ; Fri, 29 Aug 2014 00:58:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588C61A013B for ; Fri, 29 Aug 2014 00:58:45 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 48922389475AD; Fri, 29 Aug 2014 07:58:40 +0000 (GMT) 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 s7T7wcNi015230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 09:58:41 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 29 Aug 2014 09:58:38 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposal for new error response for DOIC Thread-Index: AQHPwtSXO5CQdXlhXU6xIYB1I+hv45vmTU+AgADYStA= Date: Fri, 29 Aug 2014 07:58:37 +0000 Message-ID: References: <53FF4A17.9050707@usdonovans.com> <95D175DE-C80C-4690-95D8-14ABC6393A38@nostrum.com> In-Reply-To: <95D175DE-C80C-4690-95D8-14ABC6393A38@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.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kGW05mpfw3ccagqEOB2zVArRV4E Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Aug 2014 07:58:48 -0000 Dear all A few remarks 1) I am also questioning about the backward compatibility case where a DA = is acting on behalf of a non DOIC client. The solution Steve proposes , to my view, also work in this case: if the = DA throttles a request, it will generate a Diameter too busy to the client,= so with the possible consequence that the non DOIC client do a retry to an= alternate destination. But we cannot avoid it, this is the non DOIC clien= t existing behavior. In any case we should avoid to send a new Diameter error to a non DOIC clie= nt as it can result to a non predictable behavior.=20 Among the possible solutions, one is to continue to use Diameter to busy in= all cases but with, in addition, a new AVP (a "DOIC diagnostic" AVP) whi= ch means message throttled in a DOIC case, which is generated by the DOIC r= eporting node, supported by a DOIC reacting node (which will not do retry t= o another destination) and ignored by a non DOIC client. This AVP may be = in the future take other values if needed. =20 2) some remark about the new retry. - I think a DA can do a retry in the case it has received a realm only requ= est (without destination host), and if not successful, will sent the new di= ameter error to the client. But if instead, the client had received a clas= sical Diameter too busy, it will also not do a retry to another destination= (as it only knows the realm, but not the server), so Diameter too busy see= ms here acceptable, isn't it? - If the client has sent a request with a Destination host, which is reject= ed by the reporting node (so with the new Diameter error) I do not think th= at a DA can do a retry to another destination host (as the client has reque= sted a specific Destination host). Am I wrong here? But the client may even= tually do a retry towards another destination host, according to the applic= ation case, so not so in line with the meaning of the new Diameter error re= questing no retry. - a server rejecting a request, will generate the new Diameter error, but t= he intermediate DA receiving this error may nevertheless do a retry to ano= ther destination a retry, so the meaning of the new Diameter error does not= always mean "no retry" for a reacting node.=20 To have your view on these remarks. Best raegrds. JJacques =20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: jeudi 28 ao=FBt 2014 21:57 =C0=A0: Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Proposal for new error response for DOIC I agree with doing this.=20 But I'm also concerned that the backwards compatibility issue you mention m= eans that this doesn't help in what is potentially the biggest use case for= throttling at an agent. that is, an agent throttling on behalf of a non-su= pporting client. One approach would be to define DIAMETER_THROTTLED in a separate update to = RFC 6733, in hopes that people who aren't ready to fully support DOIC might= at least support the new error. (Yeah, I know that's a long shot.) Another= might be to write some additional (BCP?) guidance on how clients should ha= ndle TOO_BUSY.=20 On Aug 28, 2014, at 10:26 AM, Steve Donovan wrot= e: > All, >=20 > One of the open issues is the DOIC behavior when a DOIC node rejects a re= quest as a result of an overload condition. >=20 > Today, the logical error response would be the DIAMETER_TOO_BUSY response= . The issue with this behavior is that it can result in the client retryin= g the request to an alternative peer. >=20 > The desired behavior for a request rejected because of overload throttlin= g is the same as if the client, acting as a reacting node, throttled the re= quest. As a result, the transaction should not be retried. >=20 > The proposal is to define a new protocol error response code called DIAME= TER_THROTTLED with the defined behavior that the request SHOULD be treated = as a final response and SHOULD NOT be retried. >=20 > This error response could be generated by agents acting as reacting nodes= or by any reporting node. A server, for instance, that is in a severe ove= rload condition might chose to reject some transactions with the DIAMETER_T= HROTTLED response if the current requested reduction included in the overlo= ad report is not sufficient. >=20 > One issue with this proposal is backwards compatibility with Diameter nod= es that do not support DOIC and, as such, would not understand the DIAMETER= _THROTTLED response. The proposal to address this is to make the generatio= n of the DIAMETER_THROTTLED error response conditional. This is an attempt= at wording this conditional behavior: >=20 > A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transact= ions that are throttled and the DOIC node knows that there is a DOIC reacti= ng node able to process the error response. The DOIC node generating the D= IAMETER_THROTTLED error response determines that there there is a DOIC reac= ting node by the presence or absence of an OC-Supported-Features AVP in the= request message for the transaction. >=20 > If there is no OC-Supported-Features AVP in the request message for a tra= nsaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_B= USY response message. >=20 > Assuming we get agreement on the proposal then I'll come back with detail= ed wording proposals for the DOIC specification. >=20 > Regards, >=20 > Steve >=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 nobody Fri Aug 29 01:37:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6E91A035C for ; Fri, 29 Aug 2014 01:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJjT1LG5VUbU for ; Fri, 29 Aug 2014 01:37:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EAC1A0306 for ; Fri, 29 Aug 2014 01:37:53 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 12CE5C4CA4975; Fri, 29 Aug 2014 08:37:50 +0000 (GMT) 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 s7T8bogX018961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 10:37:51 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 29 Aug 2014 10:37:50 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposal for new error response for DOIC Thread-Index: AQHPwtSXO5CQdXlhXU6xIYB1I+hv45vmTU+AgADYStCAABpakA== Date: Fri, 29 Aug 2014 08:37:50 +0000 Message-ID: References: <53FF4A17.9050707@usdonovans.com> <95D175DE-C80C-4690-95D8-14ABC6393A38@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.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KL_wpDH7eWlww-WiAoUZrLNVGbw Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Aug 2014 08:37:55 -0000 To come back on my point 2) , and reviewing the definition of Diameter too = busy in RFC 6733.=20 DIAMETER_TOO_BUSY 3004 When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service Does it mean that the request is sent to the same specific server but via a= n alternate path (the request contains the same Realm and host destinations= AVP but is sent to another peer (another DA) , or can the alternate peer c= orresponds to another server (so another destination host). According to th= e understanding, this impacts my Point 2) remarks Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: vendredi 29 ao=FBt 2014 09:59 =C0=A0: Ben Campbell; Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Proposal for new error response for DOIC Dear all A few remarks 1) I am also questioning about the backward compatibility case where a DA = is acting on behalf of a non DOIC client. The solution Steve proposes , to my view, also work in this case: if the = DA throttles a request, it will generate a Diameter too busy to the client,= so with the possible consequence that the non DOIC client do a retry to an= alternate destination. But we cannot avoid it, this is the non DOIC clien= t existing behavior. In any case we should avoid to send a new Diameter error to a non DOIC clie= nt as it can result to a non predictable behavior.=20 Among the possible solutions, one is to continue to use Diameter to busy in= all cases but with, in addition, a new AVP (a "DOIC diagnostic" AVP) whi= ch means message throttled in a DOIC case, which is generated by the DOIC r= eporting node, supported by a DOIC reacting node (which will not do retry t= o another destination) and ignored by a non DOIC client. This AVP may be = in the future take other values if needed. =20 2) some remark about the new retry. - I think a DA can do a retry in the case it has received a realm only requ= est (without destination host), and if not successful, will sent the new di= ameter error to the client. But if instead, the client had received a clas= sical Diameter too busy, it will also not do a retry to another destination= (as it only knows the realm, but not the server), so Diameter too busy see= ms here acceptable, isn't it? - If the client has sent a request with a Destination host, which is reject= ed by the reporting node (so with the new Diameter error) I do not think th= at a DA can do a retry to another destination host (as the client has reque= sted a specific Destination host). Am I wrong here? But the client may even= tually do a retry towards another destination host, according to the applic= ation case, so not so in line with the meaning of the new Diameter error re= questing no retry. - a server rejecting a request, will generate the new Diameter error, but t= he intermediate DA receiving this error may nevertheless do a retry to ano= ther destination a retry, so the meaning of the new Diameter error does not= always mean "no retry" for a reacting node.=20 To have your view on these remarks. =20 Best raegrds. JJacques =20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy= =E9=A0: jeudi 28 ao=FBt 2014 21:57 =C0=A0: Steve Donovan Cc=A0: dime@ietf.o= rg Objet=A0: Re: [Dime] Proposal for new error response for DOIC I agree with doing this.=20 But I'm also concerned that the backwards compatibility issue you mention m= eans that this doesn't help in what is potentially the biggest use case for= throttling at an agent. that is, an agent throttling on behalf of a non-su= pporting client. One approach would be to define DIAMETER_THROTTLED in a separate update to = RFC 6733, in hopes that people who aren't ready to fully support DOIC might= at least support the new error. (Yeah, I know that's a long shot.) Another= might be to write some additional (BCP?) guidance on how clients should ha= ndle TOO_BUSY.=20 On Aug 28, 2014, at 10:26 AM, Steve Donovan wrot= e: > All, >=20 > One of the open issues is the DOIC behavior when a DOIC node rejects a re= quest as a result of an overload condition. >=20 > Today, the logical error response would be the DIAMETER_TOO_BUSY response= . The issue with this behavior is that it can result in the client retryin= g the request to an alternative peer. >=20 > The desired behavior for a request rejected because of overload throttlin= g is the same as if the client, acting as a reacting node, throttled the re= quest. As a result, the transaction should not be retried. >=20 > The proposal is to define a new protocol error response code called DIAME= TER_THROTTLED with the defined behavior that the request SHOULD be treated = as a final response and SHOULD NOT be retried. >=20 > This error response could be generated by agents acting as reacting nodes= or by any reporting node. A server, for instance, that is in a severe ove= rload condition might chose to reject some transactions with the DIAMETER_T= HROTTLED response if the current requested reduction included in the overlo= ad report is not sufficient. >=20 > One issue with this proposal is backwards compatibility with Diameter nod= es that do not support DOIC and, as such, would not understand the DIAMETER= _THROTTLED response. The proposal to address this is to make the generatio= n of the DIAMETER_THROTTLED error response conditional. This is an attempt= at wording this conditional behavior: >=20 > A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transact= ions that are throttled and the DOIC node knows that there is a DOIC reacti= ng node able to process the error response. The DOIC node generating the D= IAMETER_THROTTLED error response determines that there there is a DOIC reac= ting node by the presence or absence of an OC-Supported-Features AVP in the= request message for the transaction. >=20 > If there is no OC-Supported-Features AVP in the request message for a tra= nsaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_B= USY response message. >=20 > Assuming we get agreement on the proposal then I'll come back with detail= ed wording proposals for the DOIC specification. >=20 > Regards, >=20 > Steve >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Aug 29 08:50:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06541A058E for ; Fri, 29 Aug 2014 08:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.732 X-Spam-Level: X-Spam-Status: No, score=0.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue0udcIqniW0 for ; Fri, 29 Aug 2014 08:50:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F961A048E for ; Fri, 29 Aug 2014 08:50:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D676A81F18308; Fri, 29 Aug 2014 15:50:36 +0000 (GMT) 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 s7TFn2Ng014029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 17:50:32 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 29 Aug 2014 17:50:04 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Issue #48 - M-bit gives wrong sementics Thread-Index: AQHPrN/gcnDHUd4VRE2L1ydZqMn82Zu6ThqAgAAD7wCAABLYgIAtYxSw Date: Fri, 29 Aug 2014 15:50:04 +0000 Message-ID: References: <53DA7458.5080301@usdonovans.com>, <30A10CA8-0B72-4878-8489-5A3156E070AA@nostrum.com> <19339_1406828489_53DA7FC9_19339_507_2_vpoow8l3d11jllgtnin7jy3y.1406828485751@email.android.com> <1D45DC43-3C0A-48AA-A5AA-8A86AFA465AA@gmail.com> In-Reply-To: <1D45DC43-3C0A-48AA-A5AA-8A86AFA465AA@gmail.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.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Wue8daG_dLttTcG_wfbSB4tSp7M Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Aug 2014 15:50:52 -0000 Hi Steve and all M-bit on which I am cautious as often at the origin of interoperability is= sues, is mentioned in different places in the 03 draft (sections 4.3, 6 a= nd 6.8) with rules according to the following: - when DOIC is supporting in an existing application, Mbit SHOULD not be se= t in DOIC AVPS (cf 6.8) - a new application can incorporate the DOIC mechanism as mandatory (cf 6),= in this case the OC-Feature-Vector and OC-OLR AVPs reused in newly defined= Diameter applications SHOULD have the M-bit flag set Some (non fundamental) remarks hereafter: a) We can have a new application where DOIC is not mandatory (when reading = 6), but in 6.8 it is stated "when reused in newly defined Diameter applicat= ions, the DOC (note: to be DOIC) related AVPs SHOULD have the M-bit set". = If DOIC is optional for this new application, Mbit is not set at least for= the OC-Supported-features AVP in the requests, so to be ignored by a non D= OIC supporting node receiving the request. May be to clarify. =20 b) We have text with general statements about DOIC AVPs and some text in 6 = (not contradictory) related to OC-Feature-Vector and OC-OLR . I think that= , in 6, OC-Supported-Feature could be added, or even replace OC-Feature-Vec= tor AVP which is a sub AVP of OC-Supported features and so already addresse= d in 4.3.=20 c) About "existing commands" in 6, sometimes an application which can be a = new one can reuse an existing command defined in another application, the M= bit rule here is attached to the application, so, to avoid misinterpretatio= n, may be better to write "commands of an existing application" in 6. d) About an intermediate proxy DA for an application but not supporting DO= IC for this application (as not needed), how does it behave when transferr= ing requests with OC-Supported-Features or OLR AVPs with Mbit set, is it c= lear that the DA transfers the DOIC AVPs and not reject them for AVP unsupp= orted? =20 e) in 4.3, it is written "NOT RECOMMENDED", I think better to write " M-bit= in sub-AVPs SHOULD not be set"=20 I hereafter remind the verison03 extracts mentioning M-bit=20 In 4.3 More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED in 6=20 When added to existing commands,both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set. However, it is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. In 6.8=20 As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9=A0: jeudi 31 juillet 2014 20:49 =C0=A0: Cc=A0: dime@ietf.org; Ben Campbell Objet=A0: Re: [Dime] Issue #48 - M-bit gives wrong sementics OK++; On Jul 31, 2014, at 8:41 PM, wrote: > Ok for me. >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > ---- Ben Campbell a =E9crit ---- >=20 >=20 > No objection >=20 > On Jul 31, 2014, at 11:52 AM, Steve Donovan wr= ote: >=20 >> All, >>=20 >> The proposal coming out of the meeting in Toronto was to close this issu= e with no changes to the existing text. >>=20 >> Let me know if there are objections to doing so, otherwise I'll close th= e issue. >>=20 >> Regards, >>=20 >> Steve >>=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 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime