Re: [Dime] DOIC: Self-Contained OLRs

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 05 December 2013 08:55 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 A4F7A1AD739 for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 00:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 bLXolF-a2b5C for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 00:55:32 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id AF5301AD72A for <dime@ietf.org>; Thu, 5 Dec 2013 00:55:30 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB58tObS007672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Dec 2013 09:55:24 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB58tOoe021901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:55:24 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Dec 2013 09:55:23 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 09:55:23 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "ext lionel.morand@orange.com" <lionel.morand@orange.com>, Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQ///0igCAAEGG8IAAESYAgAARq0CAAGUiAIAAraWggADRWYCAACcjAIAAlfeQ
Date: Thu, 05 Dec 2013 08:55:23 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D888@DEMUMBX014.nsn-intra.net>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <A9CA33BB78081F478946E4F34BF9AAA014D2228C@xmb-rcd-x10.cisco.com>, <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014D2266 B@xmb-rcd-x10.cisco.com> <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.com> <087A34937E64E74E848732CFF8354B920972B9AE@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519C248@DEMUMBX014.nsn-intra.net> <4225_1386065078_529DACB6_4225_280_1_6B7134B31289DC4FAF731D844122B36E3128C0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519C2D8@DEMUMBX014.nsn-intra.net> <21357_1386067889_529DB7B1_21357_3212_1_6B7134B31289DC4FAF731D844122B36E312A07@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519D3D9@DEMUMBX014.nsn-intra.net> <529DFD0A.9050308@usdonovans.com> <5BCBA1FC! ! 2B7F0B4C9D935572D90006681519D493@DEMUMBX014.nsn-intra.net> <A3BD26AD-8420-49E4-B481-ABFE75426FB5@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519D57E@DEMUMBX014.nsn-intra.net> <6EC4AFCD-E8BB-4EF8-92C8-3FD7387FCD9D@nostrum.com> <876_1386201807_529FC2CF_876_10551_1_6B7134B31289DC4FAF731D844122B36E3295E0@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <876_1386201807_529FC2CF_876_10551_1_6B7134B31289DC4FAF731D844122B36E3295E0@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.159.42.117]
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: 37842
X-purgate-ID: 151667::1386233725-00006154-56830CCC/0-0/0-0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] DOIC: Self-Contained OLRs
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: Thu, 05 Dec 2013 08:55:37 -0000

Ben, Lionel,

The intention is to keep things simple and avoid complexity.
There can only be one in-context OLR in an answer (i.e. one OLR that the corresponding request would have matched) and that is the OLR the reacting node must store and take into account when sending subsequent requests.
Other (out-of-context) OLRs in an answer (i.e. OLRs that the correstponding request would not have matched) should only be optional and marked in order to let the reacting node detect without referring back to the original request that this OLR is out-of-context.

Clause 5.1 describes the endpoint concept. It says:
The overload control endpoint are the two Diameter nodes that decide to exchange overload control information between each other.
In Figure 3 C and S are the enpoints with a DOIC association between C and S. S returns a host-type OLR and A must not insert a realm-type OLR or anything since it is not an endpoint having a DOIC association with C.

In Figure 5 C and A are endpoints with a DOIC association (d) between C and A. Also: A and S are endpoints with a different DOIC association (d') between A and S. The different DOIC associations d and d' may have different advertised/negotiated features and must be strictly separated. An host-type OLR sent from S to A is in-context for d' but not for d and therefore must not be forwarded transparently to C (it can be forwarded but then it must be marked as "out-of-context"). 

Ulrich



-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
Sent: Thursday, December 05, 2013 1:03 AM
To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ben, Ulrich,

Please see below.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:43
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs


On Dec 4, 2013, at 2:23 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Ben,
> 
> No. One OLR per answer (if no extension is supported).

I don't understand the intent. What difference does an extension make? Do you consider additional ReportType values to be extensions?

In particular, if we end up supporting both Realm and Server type reports in the base, I think you should be able to have one of each in an answer. But I agree, two Realm reports or two Server reports in the same answer can create a conflict.

[LM] it is why it is proposed to avoid multiple OLRs with the same report type in the same answer.

> 
> What is an ambiguous OLR?
> What should the client do when receiving 5 OLRs in one answer three of which are ambiguous?
> 
> Let's try to avoid complexity.
> 
> Ulrich 
> 
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com] 
> Sent: Tuesday, December 03, 2013 11:53 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] DOIC: Self-Contained OLRs
> 
> 
> On Dec 3, 2013, at 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
> 
>> Steve,
>> 
>> I didn't say that there can never be more than one OLR.
>> My point is that a reacting node that does not indicate support of any extension (like agent overload) must not be forced to process more than one OLR per answer.
>> 
> 
> Can we restate the "not forced to process" to say "not be forced to choose between ambiguous" OLRs?
> 
>> Ulrich
>> 
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Tuesday, December 03, 2013 4:47 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> I am strongly against saying that there can never be more than one overload report in a message.  This makes it impossible to extend the base protocol to support agent overload.
>> 
>> It also makes it more difficult to achieve the more granular differentiated overload report types that Nirav is suggesting.
>> 
>> Steve
>> 
>> On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi Lionel,
>> 
>> the more OLRs a client must process (in every answer) the more complex is the solution. I don't see how it helps that multiple OLRs are not mandated for the reporting node; the reacting node would still be required to process all received OLRs.
>> 
>> Best regards
>> Ulrich
>> 
>> -----Original Message-----
>> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
>> Sent: Tuesday, December 03, 2013 11:51 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Ulrich,
>> 
>> I don't see the complexity if each OLR instance received is clearly distinguished by the Report-Type. 
>> Again, it is not said that it will be mandated for any deployment to rely on multiple OLR instances. 
>> 
>> Regards,
>> 
>> Lionel
>> 
>> -----Message d'origine-----
>> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>> Envoyé : mardi 3 décembre 2013 11:46
>> À : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org list
>> Objet : RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Lionel,
>> 
>> my point is simple:
>> 
>> more than one OLR in an answer is not needed and adds complexity.
>> We should either not be allow additional (out-of-context) OLRs or mark them.
>> Clients must not be forced to process additional OLRs.
>> 
>> Ulrich 
>> 
>> -----Original Message-----
>> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
>> Sent: Tuesday, December 03, 2013 11:05 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Ulrich,
>> 
>> Honestly, I don't get your point.
>> It could be done as you've described below and there is no reason to prohibit this way of doing. The consequence for the client is that it will never receive more than one OLR. I think it was never mandated that an agent MUST insert a realm-based OLR.
>> But there is no reason to prohibit the presence of both OLRs in the same answer.
>> 
>> Regards,
>> 
>> Lionel 
>> 
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)
>> Envoyé : mardi 3 décembre 2013 10:21
>> À : ext Maria Cruz Bartolome; dime@ietf.org list
>> Objet : Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> Dear MCruz,
>> thank you for your support.
>> 
>> In fact we are looking at figures 3 and 5 of clause 5.1.
>> In figure 3 when C sends a request containing Destination Host to S, S returns a host-type OLR to C (via A) and there is no need for A to insert a realm-type OLR in the answer (as there is no DOIC Association between C and A in this case).
>> Note: it may well be that C never sends a request not containing a Destination Host in which case any realm-type OLR inserted by A would be useless to C. 
>> 
>> Similarly In figure 5 when C sends a request without Destination Host, A may select S and may insert a Destination Host before forwarding the request. S then returns a host-type OLR to A, and A replaces the host-type OLR received from S with a realm-type OLR. There is no need that the host-type OLR generated by S is conveyed to C (as there in no DOIC Association between C and S in this case).
>> Note: it may well be that C never sends a request containing a Destination Host in which case any host-type OLR conveyed to C would be useless to C.
>> 
>> In any case there is no need for more than one OLR in an answer.
>> 
>> Ulrich
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>> Sent: Monday, December 02, 2013 4:55 PM
>> To: dime@ietf.org list
>> Subject: Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> Dear all,
>> 
>> My interpretation is as well in line to what is summarized by Lionel below.
>> 
>> For a request towards a realm (without Destination Host), in case there is not an intermediate agent, receiving a host-based OLR may be in fact the normal behavior.
>> But I agree in case the request is towards a Destination Host, receiving the realm-based OLR could be considered an optimization, and I would agree on Ulrich's view, it could be optionally included by the reporting node, and optionally acted upon by the reacting node. In any case, if the reacting node does not take this into account when (potentially) sending a request to a realm (with no destination host), it will get back fresh information on the realm overload status in the corresponding answer, if required.
>> 
>> Best regards
>> /MCruz
>> 
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
>> Sent: lunes, 02 de diciembre de 2013 15:38
>> To: lionel.morand@orange.com
>> Cc: Ben Campbell; dime@ietf.org list
>> Subject: Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> 
>> My understanding (and current editing) has already been towards what Lionel said below.
>> 
>> - Jouni
>> 
>> 
>> On Dec 2, 2013, at 4:19 PM, lionel.morand@orange.com wrote:
>> 
>> I agree with last part. It was the reason I've reconsidered my position on the need for the Report-Type.
>> 
>> Ulrich, I think that what you are considering as out of context is just a matter of interpretation.
>> When sending a request, a client is always targeting a server, even if Destination-Host is not in the answer. So receiving a host-based OLR in response is not "out of context".
>> Receiving a Realm-based OLR in addition to a host-based OLR in answer to a request sent to the Realm is correct as soon as the client receives a positive answer from a server.
>> Receiving a Realm-based OLR in addition to a host-based OLR in answer to a request to a specific server could be seen as a "kind of optimization" offered by the use of the Report-Type. But there is nothing wrong. It is only to comply with the Diameter routing principle: subsequent requests from the client could include a destination-host or not. So the client needs to know which reduction to apply from a previous answer.
>> 
>> In any case, the client needs to store the OLR received according to the Report-type. And having the report type avoids the client to "guess" the context based on the type of request.
>> 
>> Regards,
>> 
>> Lionel
>> 
>> 
>> De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoyé : lundi 2 
>> décembre 2013 14:58 À : Wiehe, Ulrich (NSN - DE/Munich) Cc : 
>> dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben 
>> Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Ulrich,
>> 
>> Wouldn't that make reacting node's implementation more complex if it has to remember what was sent in the request while processing the response?
>> 
>> I would prefer to derive the context of the OLR based on the message which contains the OLR.
>> 
>> Back to the topic of this thread, I don't think we need to define an "optional" optimization at this stage. Either it is respected by all the nodes supporting the solution or we drop that optimization.
>> 
>> Regards,
>> Nirav.
>> 
>> On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
>> Nirav,
>> 
>> If the reacting node sends a request without Destination Host, a realm-type OLR in the answer would be in-context whereas a host-type OLR in the answer would be out of context.
>> 
>> Similarly, if the reacting node sends a request containing Destination Host, a realm-type OLR in the answer would be out-of-context and a host-type OLR in the answer would be in-context.
>> 
>> Ulrich
>> 
>> 
>> 
>> -----Original Message-----
>> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
>> Sent: Monday, December 02, 2013 12:25 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext 
>> Jouni Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Ulrich,
>> 
>> I have a basic question.
>> 
>> When the reacting node sends realm-routed request and it receives (only one) OLR in the response message (which also contains the origin-host), is this OLR applicable for realm or host?
>> I am trying to understand which is out-of-context OLR here: realm-type or host-type?
>> 
>> Regards,
>> Nirav.
>> 
>> -----Original Message-----
>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>> Sent: Monday, December 02, 2013 4:30 PM
>> To: Nirav Salot (nsalot); ext lionel.morand@orange.com; ext Jouni 
>> Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Nirav,
>> 
>> please see inline.
>> 
>> Regards
>> Ulrich
>> 
>> -----Original Message-----
>> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
>> Sent: Monday, December 02, 2013 7:05 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext 
>> Jouni Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Ulrich,
>> 
>> When the client sends request containing destination-realm (and not containing destination-host), it gets back answer containing origin-host (set by the actual server) as well as host-type OLR.
>> So purely from the response message perspective, the host-type OLR in this response message is not out-of-context information. 
>> [Wiehe, Ulrich (NSN - DE/Munich)] But we do not purely take the response message perspective. The client sends a request of type x (destination host =x1, destination realm =x2 application= x3) and gets back an OLR in the answer which says "please throttle request of the type you just sent". The client either remembers, or deduces from info received in the answer, what the type x was. E.g. it deduces from the value of Origin Realm in the answer the value of Destination Realm in the request; it deduces from the value of Report-Type in the answer whether Destination Host was present in the request...
>> 
>> On the other hand, we discussed - as part of Maria Cruz's alternative solution - to define the response message's context based on the request message. And hence if the request message was sent to destination-realm, the corresponding response message can only contain realm-type OLR.
>> But this requires the client to remember the context of the request while processing the response and hence it was considered as introducing unnecessary complexity. 
>> [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AVP is needed to let the client deduce from information received in the answer whether the request contained a destination host. It does not mean that we need two OLRs in one answer.
>> 
>> If we strictly want to ensure that the realm-type OLR is not sent 
>> out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my 
>> proposal. My proposal was to clearly mark out-of-context OLRs in 
>> answer messages (if we allow including out-of-context OLRs)
>> 
>> , then we should agree to Lionel's alternative solution - to send realm-type OLR only when the destination-realm based request is rejected. So basically, realm-type OLR is never included in a response message which contains origin-host AVP. (And I am ready to reconsider the same if we want to ensure the context of the response message and the OLR it contains).
>> 
>> However, as per our current agreement, we are introducing Report-Type AVP [Wiehe, Ulrich (NSN - DE/Munich)] I agree  to allow the inclusion of host-type and realm-type OLRs in the response message.
>> [Wiehe, Ulrich (NSN - DE/Munich)] That is not the reason; even if only one OLR is in the answer, report-type would still be needed.
>> If we say that the client can ignore one of the OLRs [Wiehe, Ulrich 
>> (NSN - DE/Munich)] only the out-of-context one
>> 
>> , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/Munich)] The in-context-OLR must be included by the reporting node and must be processed by the reacting node; the out-of-context OLR may be included as optimization by the reporting node or any agent (if the reporting node or agent wants to offer this optimization), and may be processed by the reacting node (if the reacting node wants to make use of this optimization).
>> 
>> and what is the point of defining Report-Type AVP?
>> [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from information received in the answer whether the corresponding request contained a destination host (so there is no need to remember).
>> 
>> 
>> In summary, if we define Report-Type AVP and corresponding handling at the reacting node, the reacting node must act accordingly and not ignore it.
>> [Wiehe, Ulrich (NSN - DE/Munich)]  What goes wrong when out-of -context OLR is ignored?
>> 
>> Otherwise, if we argue that the Report-Type AVP is just an optimization (to allow the inclusion of realm-type OLR) and the reacting node can ignore it, then lets not define this optimization since it has no value if it is ignored.
>> [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimization but the incusion of out-of-context OLRs. And I'm ok not to proceed with this optimization as it is not needed.
>> 
>> Regards,
>> Nirav.
>> 
>> -----Original Message-----
>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>> Sent: Monday, December 02, 2013 1:08 AM
>> To: Nirav Salot (nsalot); ext lionel.morand@orange.com; ext Jouni 
>> Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Nirav,
>> 
>> When the client sends a request that contains only destination realm but no destination host an gets back an answer containing a host-type OLR, this OLR is out-of-context.
>> Similary, when the client sends a request containing destination host and gets back an answer containing a realm-type OLR, this OLR is out-of-context.
>> There is nothing wrong with storing such out-of-context OLRs at the client, but it is simply not needed as the client will learn this OLR from responses received within the context.
>> 
>> Best regards
>> Ulrich
>> 
>> 
>> -----Original Message-----
>> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
>> Sent: Friday, November 29, 2013 4:49 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext 
>> Jouni Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Ulrich,
>> 
>> If an additional OLR is present with a different ReportType, why it should be ignored by the reacting node?
>> 
>> Regards,
>> Nirav.
>> 
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich 
>> (NSN - DE/Munich)
>> Sent: Friday, November 29, 2013 5:36 PM
>> To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Lionel,
>> 
>> there is nothing missing exept the clarification that everything works fine when only one OLR (the OLR created by the reporting endpoint) is present in the answer and additional OLRs (not created by the reporting endpoint) may just be present as an optional optimization i.e. optionally inserted by the reporting endpoint and optionally ignored by the reacting endpoint.
>> 
>> Ulrich
>> 
>> 
>> -----Original Message-----
>> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
>> Sent: Friday, November 29, 2013 11:13 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi Ulrich,
>> 
>> Using the Report Type "host report", you know that the OLR applies for subsequent request towards the origin-host of the answer containing the OLR. Using the report Type "Realm report", you know that the OLR has to be used as soon as a request needs to be sent without destination-realm. 
>> 
>> It is not so important to know what the type of request was and which node inserts this information. It can be any node having sufficient knowledge of the realm overload status. An agent in the path could be this one but, for instance, future development could allow a distributed server architecture to provide the same information.
>> 
>> I'm not sure of what is missing in this reasoning...
>> 
>> Lionel
>> 
>> -----Message d'origine-----
>> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>> Envoyé : jeudi 28 novembre 2013 11:30 À : MORAND Lionel IMT/OLN; ext 
>> Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE: 
>> [Dime] DOIC: Self-Contained OLRs
>> 
>> Lionel,
>> 
>> my understanding was that _the_ reporting end point provides _the_ OLR.
>> 
>> If we go for two OLRs in the answer we should indicate which OLR is the actual OLR created by the reporting end point and which OLR is an additional OLR created by another node.
>> 
>> We have two cases:
>> a) The request sent by the client (reacting end point) contains no Destination Host. The agent (reporting node) (after forwarding the request to the selected server and receiving the answer) returns a realm-type OLR as the actual reporting-node-created OLR and optionally in addition a host-type OLR as learned from the selected server.  The client may ignore the additional OLR.
>> b) The request sent by the client (reacting endpoint) contains the Destination Host. The Server (reporting node) returns a host-type OLR as the actual reporting-node-created OLR in the answer. The agent may optionally insert a realm-type OLR as additional OLR to the answer. The client may ignore the additional OLR.
>> 
>> Ulrich
>> 
>> 
>> 
>> -----Original Message-----
>> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
>> Sent: Thursday, November 28, 2013 10:31 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi,
>> 
>> There is no assumption on which entity is providing the realm overload status. It could be provided an agent inserting this info in answers received from a server behind but also from a server that would know this info by some internal magic.
>> But in any case, if we assume that the client will received a successful answer from the server for an initial request with only Dest-Realm AVP, it should be possible to have both report types in the answer: one for the server itself, one for the realm for new request sent to the realm with only Dest-Realm AVP.
>> 
>> Lionel
>> 
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich 
>> (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni 
>> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] 
>> DOIC: Self-Contained OLRs
>> 
>> Hi,
>> 
>> I don't see how the possibility to send more than one OLR in an answer is aligned with the "endpoint principle". If the ReportType is "realm" this indicates to the reacting end point that the reporting end point is an agent (e.g. SFE) rather than a server. If the ReportType is "host" this indicates to the reacting end point that the reporting end point is a server. How can the reporting end point be both agent and server?
>> 
>> Ulrich
>> 
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni 
>> Korhonen
>> Sent: Wednesday, November 27, 2013 11:44 PM
>> To: Ben Campbell
>> Cc: dime@ietf.org list
>> Subject: Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> 
>> On Nov 28, 2013, at 12:27 AM, Ben Campbell <ben@nostrum.com> wrote:
>> 
>> Hi,
>> 
>> I mentioned in another thread that I prefer putting an explicit 
>> ReportType AVP in an OLR, rather than
>> 
>> The more I spent time thinking/writing the actual procedures on the endpoints, the more it makes sense to me to keep the ReportType in the OC-OLR. Even if the baseline does not have agent overload etc, the ReportType fits well to the "endpoint principle" we have in the draft. It indeed gives more tools to make a host vs. realm base decision on the reacting node and is plain more clear.
>> 
>> I skip the rest of the mail.. too much text ;-)
>> 
>> 
>> - Jouni
>> 
>> 
>> 
>> 
>> 
>> making a responding node infer the type or meaning of the OLR from a Diameter request that corresponds to the answer containing the OLR. My reasons for that go beyond just ReportType, so I'm starting a separate thread.
>> 
>> As currently described, a consumer of an OLR must infer several things from other context. In most cases, that context is in the Diameter answer that carries the OLR. For example, the OLR implicitly refers to the application identified by the Application-Id field of the enclosing answer, the realm identified by Origin-Realm, and so on. This means that the "meaning" of an OLR cannot be determined from the OLR contents alone; OLRs only have meaning in the context of the enclosing answer. If you moved an OLR from one answer to another, it's meaning may change completely.
>> 
>> I think this approach is a mistake. I would greatly prefer that we explicitly include such values in the OLR itself, for multiple reasons:
>> 
>> 1) It's more complex to interpret implicit, contextual values than explicit values. The consumer cannot simply look at the OLR; it must look in various other AVPs to find all the information it needs. For example, I think a common software design for overload control processing to be separated from application processing. The consumer cannot simply hand the OLR to that module and expect things to work. The OC module must not only parse the OLR, but parse any other AVPs that are relevant. As OLR contents get extended (assumedly following the same strategy as the base spec), the number of "context" avps that must be interpreted can grow large. This approach is error prone, and will likely encourage brittle, hard-to-maintain code. Self-contained OLRs would keep all the information related to overload in one place. making for simpler implementations.
>> 
>> 2) It's more complex for the reporting node to send implicit values than explicit values. The sender cannot simply set the context to match the OLR--all those other AVPs have application or protocol layer meanings. Once a reporting node realizes that it is overloade, it has to wait for the right answer that contains the right context before it can send the OLR. This is particularly troublesome for agents, since they will typically have to insert OLRs into answers created by other nodes. 
>> 
>> If the reporting node screws this up, the meaning of the OLR may change significantly. So again, implicit meaning gives us error prone implementations. Self-contained OLRs are simpler to create and send.
>> 
>> 3) Implicit values don't work at all for certain problems. For 
>> example, if an agent needs to originate an OLR, it typically needs 
>> to insert that OLR into an existing Diameter answer created by a server.
>> It can't create its own answer without affecting the application 
>> state. If the responding node assumes the OLR comes from or refers 
>> to the node identified by the Origin-Host AVP in the enclosing 
>> answer, things break. (For examples of when an agent needs to send 
>> OLRs that are distinct from those sent by a server, see Steve's 
>> agent overload draft, or my dh/dr example.)
>> 
>> OTOH, explicit values will work for all cases where we need to associate some arbitrary value with an OLR.
>> 
>> 4) Implicit values seriously constrain the future evolution of Diameter OC standards. For example, lets say we find a good reason to allow OLRs to be sent out of band, or be sent in a dedicated Diameter application. If overload reports were self-contained, one could just reuse the report format we specify here. But if the meaning of an OLR depends on the way it's transported, this won't work. We would have to create a new or significantly modified OLR format if we found a need to transport OLRs in different ways. Self-contained OLRs would allow much greater flexibility.
>> 
>> So, in summary, I think that self-contained OLRs would lead to simpler implementations, less brittle deployments, and more flexibility for future evolution of standards.
>> 
>> Thanks!
>> 
>> Ben.
>> _______________________________________________
>> 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.
>> 
>> _______________________________________________
>> 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.
>> 
>> 
>> _______________________________________________
>> 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.
>> 
>> _______________________________________________
>> 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 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.