Re: [Dime] DOIC: Self-Contained OLRs

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Wed, 11 December 2013 08:27 UTC

Return-Path: <jean-jacques.trottin@alcatel-lucent.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 88B0E1AE20A for <dime@ietfa.amsl.com>; Wed, 11 Dec 2013 00:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GL_JdWkLgtH9 for <dime@ietfa.amsl.com>; Wed, 11 Dec 2013 00:27:53 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EFC321AE208 for <dime@ietf.org>; Wed, 11 Dec 2013 00:27:52 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rBB8RdmW008146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Wed, 11 Dec 2013 02:27:41 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBB8RcHr021950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Wed, 11 Dec 2013 09:27:39 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 11 Dec 2013 09:27:39 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/uc4Hi6cqE9USGBLWwFB86UZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9A=
Date: Wed, 11 Dec 2013 08:27:38 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D201CB4AA4@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <529CA930.4030006@usdonovans.com> <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AB88923-E019-4EAF-9512-E677D5798DB3@nostrum.com> <17146_1386112679_529E66A7_17146_16391_1_6B7134B31289DC4FAF731D844122B36E31A900@PEXCVZYM11.corporate.adroot.infra.ftgroup> <C86346CB-2D05-44C1-8ED6-2ABB15711671@nostrum.com> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D24EFF@xmb-rcd-x10.cisco.com> <52A077CC.3000004@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D2582D@xmb-rcd-x10.cisco.com> <52A088D0.2020406@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D25A08@xmb-rcd-x10.cisco.com> <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se> <D3716AC2-10E5-4E7C-95A1-87BCAA88CFE9@gmail.com> <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.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: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201CB4AA4FR712WXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
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: Wed, 11 Dec 2013 08:27:55 -0000

Hi Ben and all

I remind my mail of 05/12, where the self contained OLRs approach is quite similar to the self contained scopes  of Draft Roach which drives to multiply the number of AVPs in the OLRs (AVPs identifying Application, destination Host or even a list of Destination Hosts,  Origin-Host etc ) with all the combinational aspects behind (a list of such combinational were addressed in draft Roach).
This also result in a piggybacking  to be done  in any message , as the self contained OLR may contain many things which are not related to the answer message conveying the self contained OLR . This also  implies that at each hop, the self contained  OLRs are opened to be reprocessed in order to recreate  new self contained OLR(s)  to various destinations.
I remind that, now 6 months ago:
Many companies considered these scopes  approach too much complex, and all people including you  or your colleagues agreed to evolve towards a more simple way to proceed, which drove to the current draft content. This decision is a strong argument that still prevails  for the current baseline described in the current draft.

This is why I remain in favor of the baseline  described in the current  draft, as as I have always and regularly  expressed for  a while.

As also said, when news requirements will appear (eg session group or APN examples)  the baseline is extensible to support these new requirements .  I prefer this way of progressive extensions , rather than to create a self contained OLR  with an  immediate and not needed complexity

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Shishufeng (Susan)
Envoyé : mardi 10 décembre 2013 04:58
À : Ben Campbell; dime@ietf.org list
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Each solution has its pros and cons. The key point here is to select a right one which could satisfy the requirements but with less resource consuming.

Quick thinking on the pros you listed for self-contained OLR.


-          The first two pros can be seen as optimization, on which we are still arguing if these optimization are worth doing or not, since such optimization brings extra cost.

-          The third one is not a key issue, which could be addressed with several ways as discussed. As a last resort, the overloaded server may send something in a request towards the client to inform the end of the overload.

-          The last three pros are mainly for the case of overload of agent, if I understood them correctly. Overload of agent is still a controversial scenario, we may need more discussion in the future. But anyway, with definition of new AVPs containing the application-id, host, realm information as implied by the piggybacking messages in the draft, as complement to the OLR so far defined, they could reach the same intention as with the self-contained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: dime@ietf.org<mailto:dime@ietf.org> list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

I am willing to call the discussion concluded for the purposes of what goes in version 01 of the DOIC  draft. But I'd like to poke a little more on what we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, Maria, and Susan), and 3 in favor (Martin, Steve, and obviously me.) I don't think that fits the usual definition of rough consensus. So I'd like to look at the pros and cons a little more explicitly. Here's my view of them. I'm sure others will have other views--but I've yet to see those in the first group explain what they think the pros of implicit OLRs might be beyond those that I've included. I've also omitted any appeal to software layering, since people disputed that already.

It would also be good to hear from anyone who has not already weighed into this.

Self-Contained OLRS:

Pros:

  *   Allows an easy, generic solution to Maria's "all-application" scoped overload use case.
  *   Allows an overloaded node to signal overload for multiple applications at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not being able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requiring inconsistent behavior.
  *   Allows out-of-band transmission of OLRs without a new format
  *   Makes it easier to do things like adding a dedicated application for overload, without a new format. (Yes, I think there's still a use case for that, and I will detail it shortly.)
Cons:


  *   The recipient cannot assume an OLR matches the context of the transaction in which it is received.
  *   It's different than what's in the draft.

Implicit OLRs:

Pros:

  *   The recipient can infer the OLR scope from a combination of the transaction context and the report type. [I don't understand why this is valuable, but am including it since people mentioned it.]
  *   Currently described in the draft.
Cons:

  *   Would need special-case behavior to allow the "all-application" scope.
  *   An overloaded node needs to send a separate report for every supported application.
  *   Needs special-case behavior to solve agent overload
  *   Cannot signal the end of a loss algorithm 100% overload condition
  *   cannot be used out-of-band.
  *   cannot be used with dedicated applications.



On Dec 9, 2013, at 5:09 AM, Jouni Korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>> wrote:


OK. Lets call this thread concluded then. I keep the old OC-OLR  semantics
regarding its information context then unmodified.

- Jouni