Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 09 September 2014 10:57 UTC
Return-Path: <ulrich.wiehe@nsn.com>
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 7B5971A6FC7 for <dime@ietfa.amsl.com>; Tue, 9 Sep 2014 03:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.701
X-Spam-Level:
X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, 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 jfo7LvmuF61b for <dime@ietfa.amsl.com>; Tue, 9 Sep 2014 03:57:42 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C981A6FC6 for <dime@ietf.org>; Tue, 9 Sep 2014 03:57:41 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s89AvbNm016893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Sep 2014 10:57:37 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s89AvbDd016441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 12:57:37 +0200
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Sep 2014 12:57:37 +0200
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 12:57:37 +0200
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>, "maria.cruz.bartolome@ericsson.com" <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>, "draft-ietf-dime-ovli@tools.ietf.org" <draft-ietf-dime-ovli@tools.ietf.org>
Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgA==
Date: Tue, 09 Sep 2014 10:57:36 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net>
References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <E194C2E18676714DACA9C3A2516265D2026C2A8B@FR712WXCHMBA12.zeu.alcatel-lucent.com>
In-Reply-To: <E194C2E18676714DACA9C3A2516265D2026C2A8B@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.115]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 10600
X-purgate-ID: 151667::1410260257-00002A30-20BCC430/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K3CFA5ET8b60dv0bGamuBBq-7wM
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 10:57:45 -0000
Dear JJacques, assume the following example: In step 1 (realm routed request sent from Client to Agent), the client indicates that it supports loss. In step 2 (host routed request send from agent to S1), the agent indicates that it supports loss and rate. In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicates that it selected rate. Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition to the realm-type OLR of loss. Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answer "use loss for realm routed requests and rate for host routed requests" Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer). I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the answer that corresponds to a realm type request. Best regards Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alcatel-lucent.com] Sent: Tuesday, September 09, 2014 12:01 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful answer to the client with origin host = S1 and an Host type OLR related to S1. As the client will have further Host routed requests to this S1 host, it seemed good for the client to be immediately informed of the S1 host overload, so to apply throttling to further S1 host requests. This has no impact on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OLR in the answer and also, as in step 4) the Host type OLR related to the Origin Host S2. This works. The point that was discussed in our previous discussions, is that the answer will contains two OLRs a realm type one and a host type one, which was accepted at this time. Is it this point you consider as an issue, and why? b) this drives to some other remarks. The IETF draft indicates that, in 5.3, when a reporting node requests traffic reduction, it sends OLRs in all answer messages (with the additional MCRuz proposal that if not present this means no change), so this drives to have a realm type OLR related to the Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related to the Origin-Host AVP (when overloaded) of the same answer. The example in a) is one such case. Do you want to modify 5.3 to introduce additional rules, which ones? Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 8 septembre 2014 16:21 À : dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tracker Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent reports Host overload directly back to the Client, when the Client request was for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=DH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=DH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=R) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. -- -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/70> dime <http://tools.ietf.org/wg/dime/> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendi… dime issue tracker
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Ben Campbell
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Maria Cruz Bartolome
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Maria Cruz Bartolome
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Ben Campbell
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Ben Campbell
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Maria Cruz Bartolome
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Steve Donovan
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Steve Donovan
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Steve Donovan
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Maria Cruz Bartolome
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… Maria Cruz Bartolome
- Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): App… dime issue tracker