Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Fri, 26 September 2014 10:43 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 B653A1A1AD1 for <dime@ietfa.amsl.com>; Fri, 26 Sep 2014 03:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pAQKnywwZh_X for <dime@ietfa.amsl.com>; Fri, 26 Sep 2014 03:43:26 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72561A1A96 for <dime@ietf.org>; Fri, 26 Sep 2014 03:43:25 -0700 (PDT)
X-AuditID: c1b4fb25-f791c6d00000617b-7d-5425434bb1ad
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.DE.24955.B4345245; Fri, 26 Sep 2014 12:43:23 +0200 (CEST)
Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 12:43:23 +0200
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.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] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0IAAAbHw
Date: Fri, 26 Sep 2014 10:43:23 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se>
References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <E194C2E18676714DACA9C3A2516265D2026C30A4@FR712WXCHMBA12.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <E194C2E18676714DACA9C3A2516265D2026CCAD1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja63s2qIwa/7JhZze1ewWSw/3sBs sen8OhaLdW9XMDmweLQ+28vqsWTJTyaPn+uvsnt8ufyZLYAlissmJTUnsyy1SN8ugStj3v3l zAVHrCqmvtzG1MD4Wa+LkZNDQsBE4srTDUwQtpjEhXvr2boYuTiEBI4ySnQ/P8gI4SxmlLg8 bTUbSBWbgJ3EpdMvmEASIgJNTBKbPk9jB0kIC2RJfOjbCmaLCGRL3GpdDtTNAWRHSby6kgQS ZhFQlTh6ZyfYHF4BX4lNO2exQyy4xywx/d8qsASnQIDE7k23WUFsRqCTvp9aA3Yes4C4xK0n 86FOFZBYsuc8M4QtKvHy8T9WCFtJYu3h7SwQ9XoSN6ZOYYOwtSWWLXzNDLFYUOLkzCcsExhF ZyEZOwtJyywkLbOQtCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhTB7f8Vt3BePmN 4yFGAQ5GJR7eBSdUQoRYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA6OT4u771y5c+/onhnuWUYtz5I8nTd0T30kwc9uasNxfn77O4Pnp6b+Uq6RjnkU83LdO IItl9jvjvdm1BqlzWZwephsYCf9gfGB/bTrLYkmuJg4JA6dvFxz8uCX53q7/9+9W498De4Ok vsiW2u3/aMB6Uy88/0byBQnNRRs5Owq9ioyipjRwTVRiKc5INNRiLipOBADfe9cLigIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wGFwCRuP_bw6kEkyPU4K-gjgFqU
Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
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: Fri, 26 Sep 2014 10:43:29 -0000

Ulrich,

Your clarification does not contradict my understanding.
However, I think in clause 6.6 it is better to clearly state what OC-Report-Type identifies first, and then how the reacting node identifies if an overload abatement applies, and for this, refer to OCS, since this is what the reacting node will use to apply abatement, if required. This is my intention with the new proposal.
I hope this clarifies.
Regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: viernes, 26 de septiembre de 2014 12:38
To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org
Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

Mcruz, JJ,

Maybe I missed your point, but my understanding is a bit different. 
Please see the attached proposal.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Friday, September 26, 2014 11:58 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

Dear JJ, all

I think I understand your concern.
I modified text in clause 6.6 to clarify this point. Attached.
Let me know your opinions.
Best regards
/MCruz


-----Original Message-----
From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alcatel-lucent.com] 
Sent: viernes, 26 de septiembre de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org
Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host


Hi Maria Cruz

1) The hereafter proposed text  is in a sub part of section 6.6 addressing  the overload treatment when the  OC-report type indicates realm report so according to a Realm type OLR. The proposed  text mentions "...Origin-Host AVP of the received message that contained the OC-OLR AVP". This  OC-OLR AVP can be understood  as the Realm type OLR subject of this section 6.6 subpart (this was my first reading), but it is another report which is a host type OLR generated by this peer. 
As you said we have to distinguish when either a host or a realm report to be applied, so here the proposal is to exclude from the text the case where the reacting node has an active type Host type OLR of which the Origin Host match the peer identity, as for this case the host type OLR will be applied. On this basis I would propose write "Host type OC-OLR AVP" as hereafter.   

"The Destination-Host AVP is absent in the request and the value of peer identity associated with the connection used to send the request does not match the value of the Origin-Host AVP of a received message that contained a Host type OC-OLR AVP"

2) When thinking a bit more to this case where the reacting node is directly connected to the reporting node (eg a Client directly connected to two or more servers, without intermediate DA, or a DA acting as a reacting node directly connected to servers). The servers usually only send Host type reports (I know there  is a  debate on servers sending realm reports), so the reacting node will not receive Realm reports.  For requests for which there is no destination Host, the reacting node will select the peer according to the host OLRs  it has or not for each of the peers (eg a peer that is not overload or with a small overload )  and then apply the abatement/throttling according to the Host type OLR of this peer. I think we have the same understanding.       


Best regards

JJacques 

-----Message d'origine-----
De : Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]
Envoyé : jeudi 25 septembre 2014 18:28
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org
Objet : RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

Dear JJ,

I do not understand your point.

Proposed clarification has the purpose to allow a reacting node to distinguish when either a host or a realm report shall apply.

Some time ago we based such a distinction on the presence (meaning host report) or absence (meaning realm report).
Now we have covered the case for host reports when the host is absent but it refers to the directly connected peer. Therefore, just absence does not allow the reacting node to identify it has to apply a realm report.

Let me know if this clarifies, or if I may be missing your point.
Thanks
/MCruz


-----Original Message-----
From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alcatel-lucent.com]
Sent: viernes, 12 de septiembre de 2014 14:13
To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolome
Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

Hi MCruz

The proposed  text applies to the realm report. 

Realm OLRs (in particular with same seq number) may be conveyed in answers with different Origin-host (but with same Origin realm), so what means to refer "to the Origin-Host AVP of the received message that contained the (realm type) OC-OLR AVP". This is different  from the Host report, where the host type OC-OLR always refers to the origin host  of the answer.
  
Can you  clarify and give a use case / topology case.

Best regards

JJacques


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : vendredi 5 septembre 2014 16:16 À : dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

I agree.

On 9/5/14, 2:40 AM, dime issue tracker wrote:
> #69: Report Type - Realm, with absent Destination-Host
>
>   In clause 6.6, host report was updated to add:
>
>   ... or the Destination-Host is
>         not present in the request but the value of peer identity
>         associated with the connection used to send the request matches
>         the value of the Origin-Host AVP of the received message that
>         contained the OC-OLR AVP.
>
>   but this clarification needs to be included as well for realm report.
>
>   Original text:
>
>      1  A realm report.  The overload treatment should apply to requests
>         for which all of the following conditions are true:
>
>         The Destination-Host AVP is absent in the request.
>
>         ...
>
>   Proposed text:
>
>      1  A realm report.  The overload treatment should apply to requests
>         for which all of the following conditions are true:
>
>         The Destination-Host AVP is absent in the request and the the value
>   of peer identity associated with the connection used to send the request
>   does not match the value of the Origin-Host AVP of the received message
>   that contained the OC-OLR AVP.
>

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