Re: [Dime] OVLI: comments to 4.6

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 09 December 2013 09:15 UTC

Return-Path: <jouni.nospam@gmail.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 9F6181AE225 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 01:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 Z8_VEtD85ePx for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 01:15:16 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E06471AE0CE for <dime@ietf.org>; Mon, 9 Dec 2013 01:15:15 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id ep20so1321802lab.6 for <dime@ietf.org>; Mon, 09 Dec 2013 01:15:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GeNrJr4IdAdvJVaccemWcIoBqQ71qR/LrWTRSg2d/2w=; b=RCq95TsHx0PrVsMeOYUdHXFFB8CQp6IK06R6JfVW0/viiqMhGePMnfbZtPGxYA3kX1 k+JKEcI6vXCJd7/yyX5U0R9EPpsvAOc8JH0gG3kEbOOKmLFv1fvQFPPc2mejmkbg3I+B Omo9z27N2PQEgHZ5RcTH1TlxsXY9jYRpQJtxn4vs9llF9fedw9kABn7uK+YHF4w3+Luu DZ3yVyTDdZ1wxHQ95R1x5sSUu9lso9z+20bgrqdg/ruFxiUw+nVhSM0PlsD4Aj4k2Hy5 hJQpFxmcTrmJlK9Whh+CRLySK26ZspAPPEdFS8z5C/rzY4NkVaWWcZTcUo6eKuTODOfk 7gfQ==
X-Received: by 10.152.234.37 with SMTP id ub5mr1770243lac.51.1386580510490; Mon, 09 Dec 2013 01:15:10 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id a8sm13087504lae.5.2013.12.09.01.15.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 01:15:07 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net>
Date: Mon, 9 Dec 2013 11:15:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1501D20-32CA-425F-A3AA-82D7A61A100E@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] OVLI: comments to 4.6
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: Mon, 09 Dec 2013 09:15:18 -0000

On Dec 6, 2013, at 4:17 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>; wrote:

> Hi Jouni,
> 
> maybe that my proposal is just kind of repackaging. But still I think it is much clearer than the existing text, and you seem not to object.
> Please consider accepting the proposed modification.

I just stopped there because the provided text from my point of view
did not solve the core of the problem.

From my point of view, the feature announcement and new report types
need to be linked. Whether the report type is an enumerated or an
unsigned integer makes no difference.

- Jouni



> 
> Best regards
> Ulrich
> 
> -----Original Message-----
> From: ext Jouni [mailto:jouni.nospam@gmail.com] 
> Sent: Friday, December 06, 2013 1:33 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.6
> 
> 
> On Dec 6, 2013, at 2:10 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> 
>> Dear all,
>> 
>> here are comments to clause 4.6:
>> 
>> It has already been proposed to change the type of the OC-Report-Type AVP from Enumerated to Unsinged64 in order to avoid potential extensibility problems.  
> 
> I do not see how changing the type to unsigned would help with the extensibility on
> an assumption we create an IANA maintained registry for it. Unsigned64 will have
> exactly the same issues as enumerated unless we define report type semantics to
> something like what we have on OC-Feature AVP. How the receiver of the report type
> reacts when it sees a flag bit that is does not understand? If the content and
> handling  of the OC-OLR somehow depends on the unknown flag bit, the receiver has
> no other choice than drop the OLR, since it cannot be sure how to handle the report
> as a whole.
> 
> The only ways around I see here are:
> a) you can extend report types when defining new applications
> b) or when both ends have a mutually supported & advertised feature that maps
>   to a report type (that has been defined after the publication of this 
>   spec)
> 
> Other than those, IMHO, are just repackaging the issue into different form.
> 
> 
> - Jouni
> 
>> In addition to that, I think that the purpose of the Report-Type is to let the reacting node know to which (future) request commands the overload treatment should apply:
>> 
>> For a host report-type the overload treatment should apply to all request commands for which
>> a) The request command's Application-ID matches the Application-Id of the OC-Report-Type AVP's encapsulating answer command and
>> b) The request command's Destination-Host is present and 
>> c) The request command's Destination-Host matches the Origin-Host of the OC-Report-Type AVP's encapsulating answer command
>> 
>> For a realm report-type the overload treatment should apply to all request commands for which
>> a) <see a) above> and
>> d) The request command's Destination-Host is absent and 
>> e) The request command's Destination Realm matches the Origin-Realm of the OC-Report-Type AVP's encapsulating answer command.
>> 
>> The proposal now is to assign individual bits of the Unsinged64 type to a), b), c), d), and e):
>> 
>> Proposed text:
>>  4.6 OC-Report-Type AVP
>> 
>>  The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contains a 64 bit flags field of a request
>>  command's characteristics.
>> 
>>  The following characteristics are defined in this document:
>> 
>>  APPLICATION_ID_MATCH (0x0000000000000001)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  to those request commands with an Application-ID that matches the Application-Id of the OC-Report-Type AVP's
>>  encapsulating answer command.
>> 
>>  DESTINATION_HOST_PRESENT (0x0000000000000002)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  to those request commands containing a Destination-Host AVP.
>> 
>>  DESTINATION_HOST_MATCH (0x0000000000000004)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  To those request commands with an Destination-Host AVP that matches the Origin-Host of the OC-Report-Type AVP's
>>  encapsulating answer command.
>> 
>>  DESTINATION_HOST_ABSENT (0x0000000000000008)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  to those request commands not containing a Destination-Host AVP.
>> 
>>  DESTINATION_REALM_MATCH (0x0000000000000010)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  to those request commands with an Destination-Host AVP that matches the Origin-Host of the OC-Report-Type AVP's
>>  encapsulating answer command.
>> 
>>  Combinations other than 
>>  1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOST_MATCH
>>  and
>>  2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_MATCH
>>  require a mutually agreed extension.
>> 
>> 
>> 
>> 
>> One extension required by 3GPP applications is the Overload Mitigation Differentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this, a new value would be needed e.g.
>> 
>>  ORIGIN_HOST_MATCH (0x0000000000000020)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  to those request commands with an Origin-Host AVP that matches the Destination-Host of the OC-Report-Type AVP's
>>  encapsulating answer command.
>> 
>> With this extension the following additional combinations would be allowed:
>> 3) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOST_MATCH and ORIGIN_HOST_MATCH
>> and
>> 4) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_MATCH and ORIGIN_HOST_MATCH
>> 
>> Another potential extension is Diameter Agent Overload. To address this, a new value would be needed e.g.
>> 
>>  NEXT_HOP_MATCH (0x0000000000000040)
>> 
>>  When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
>>  to those request commands sent to the same next hop the OC-Report-Type AVP's encapsulating answer command was received from.
>> 
>> 
>> Best regards
>> Ulrich
>> 
>> 
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>